Authentication Method Reference Values
draft-ietf-oauth-amr-values-08

Thank you for addressing by DISCUSS and comment.

In 6.1, the text seems to say experts must enforce one of two different standards for handling characters outside the non-printable ascii set. Is that the intent? That seems to invite inconsistent decisions from different experts. Would it make more sense to say that experts must make sure one of the two standards is met, rather than choosing which standard they want to follow?

Thanks for this useful document.

I plan to support its approval shortly, but I think we need to finish the discussion we had with Paul's Gen-ART review. I think I'm starting to agree with Mike, but this is worthwhile to point out to the IESG during our deliberations tomorrow.

(The issue is whether as per RFC 5226 one sends a request to a DE and he or she may send it to mailing list, or if IANA should send the request directly to a mailing list. But I think the language in draft-leiba-cotton-iana-5226bis is looser on this respect, as it probably should be. Or I thought the language is looser... but opinions seem to differ. Maybe we need to send mail to the authors of 5226bis to ask for clarification-)

Could the values in this registry also be used for draft-ietf-kitten-krb-auth-indicator-06?

Thanks for clarifying that amr represents classes of auth methods and 
not (always) individual methods, that all makes more sense now;-)

I think you might usefully add the phrase "classes of" (or similar) to
the draft in a few places to help folks understand that, in particular,
I spotted two places where I think something like that'd be good:

1. in the definition, I'd suggest:

OLD:

 amr
      OPTIONAL.  Authentication Methods References.  JSON array of
      strings that are identifiers for authentication methods used in
      the authentication. 

NEW:

 amr
      OPTIONAL.  Authentication Methods References.  JSON array of
      strings that are identifiers for classes of authentication methods used in
      the authentication. 

2. In the IANA considerations and DE guidance, maybe make the name
of the new registry reflect that these are classes, in case someone gets
confused only having looked at the IANA pages without reading the RFC,
and perhaps point the DE guidance back to the top bit where you explain
this stuff and add "classes of" in a few places in the template to save
the DEs having to explain that over and over to people who just copy
templates.

Thanks,
S.