Issue 141: "should we have an auth scheme registry"

Hi there,

this issue has been waiting for the authentication framework to become 
part of P7. Now that this has been resolved experimentally (pending IESG 
approval), we can get back to it.

Things to decide:

1) What kind of registration requirements do we want to have?

2) How do we populate the registry?

3) Which schemes do we want to populate the registry with?

Proposal:

1) Same as status codes and method names, meaning "IETF Review", as 
defined in <http://tools.ietf.org/html/rfc5226#section-4.1>:

       IETF Review - (Formerly called "IETF Consensus" in
             [IANA-CONSIDERATIONS]) New values are assigned only through
             RFCs that have been shepherded through the IESG as AD-
             Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
             intention is that the document and proposed assignment will
             be reviewed by the IESG and appropriate IETF WGs (or
             experts, if suitable working groups no longer exist) to
             ensure that the proposed assignment will not negatively
             impact interoperability or otherwise extend IETF protocols
             in an inappropriate or damaging manner.

             To ensure adequate community review, such documents are
             shepherded through the IESG as AD-sponsored (or WG)
             documents with an IETF Last Call.

             Examples: IPSECKEY Algorithm Types [RFC4025],
             Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
             Handshake Hello Extensions [RFC4366].

2) Same as for method names - include the registrations into a separate 
document (this avoid having a normative dependency on 2617 in Part 7).

3) Obviously "basic" and "digest". What about RFC 4559 though (register 
it, but point out the problems?)

Feedback appreciated,

Julian

Received on Monday, 13 September 2010 16:16:50 UTC