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
