Re: [regext] review of draft-ietf-regext-login-security-03

["Patrick Mevzek" <[e-mail]>]

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
  [e-mail]