Patrick,
So my point was: - don't think password policies can be condensed into a regular expression (that may be the case for one registry, but certainly not for all, so I see no need to try enforcing that) I’m not claiming that all password policies can be condensed into a regular expression, but at a minimum the syntactical policy can. Other factors associated with the password policy can be handled in discussions around draft-gould-regext-login-security-policy. - don't put things like that in "human" readable parts I’m not proposing that password expression should be placed in the human readable message, but I’m pointing out that it can if a server desires to do so. The server can also place the example message that you provided. The draft does not need to define what is provided in the human readable message. — JG James Gould Distinguished Engineer [email protected] 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/9/19, 5:21 PM, "regext on behalf of Patrick Mevzek" <[email protected] on behalf of [email protected]> wrote: On Tue, Apr 9, 2019, at 16:01, Gould, James wrote: > The password expression can be included in the error response using the > human readable message per registry policy, which will work for > troubleshooting purposes only, since the human readable message should > not be parsed by the client. The login security extension is not well > suited for communicating policy information, which is the point of > draft-gould-regext-login-security-policy. The password policy > information can be formally communicated via > draft-gould-regext-login-security-policy over EPP or using an > out-of-band mechanism. That was exactly Martin's point on which I was replying: <quote> I know that you have foreseen draft-gould-regext-login-security-policy to query about password complexity but I think for convenience of the registrar it would still be nice to somehow include the password requirement in the response even if it is redundant. Otherwise one has to implement draft-gould-regext-login-security-policy at the same time or communicate the requirement out of band. </quote> And the example given clearly used an attribute to store the regex, which is clearly not human redable. And again there is no "password expression" since like I tried to show but failed apparently, not all password policies can be compressed into one regular expression. And also putting such kind of things (regex) into a "human" readable message makes no sense. (it is neither human nor readable) It would be far more logical to have a human readable message saying: "Password not in compliance with rule A.III.b.3.i of regulations at https://www.registry.example/a_super_nice_documentation.pdf"; So my point was: - don't think password policies can be condensed into a regular expression (that may be the case for one registry, but certainly not for all, so I see no need to try enforcing that) - don't put things like that in "human" readable parts Finally, like I said, piggybacking everything on another EPP extension risks for now the fact that not a lot of registries will implement it. Each extension should try to stand-alone as much as possible... Otherwise in your current setup a registry needs to implement this extension, the core policy one, and then the extension on the policy one. I have low hope this will happen... And the amount of discussions around this -- Patrick Mevzek [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
