> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Tschofenig, Hannes (NSN - FI/Espoo) > Sent: Tuesday, June 22, 2010 11:08 PM > To: OAuth WG > Subject: [OAUTH-WG] Extensibility for OAuth? > > Hi Eran, > Hi all, > > I briefly browsed through the -08 version of the draft to figure out what > could be written about extensibility. Here are a few thoughts: > > - Client Profiles > > This is probably the most important item were people will want to write > extensions for. Currently, we have the following onces in the document: > 1) Web Server > 2) User Agent > 3) Native Application > 4) Autonomous > Note that the actual profile identifiers aren't clearly listed in the > document > at the moment (or are inconsistent, such as "user_agent" and "user-agent" > for the user agent profile).
Profiles are not normative language, they are just examples of the authorization and token endpoints can be used (profiled) for particular use cases (the most common ones). This is why this has been moved to the introduction. Instead, the spec now talks about grant types, providing three primary types (user basic credentials, authorization code obtained from the authorization endpoint, and assertion). The assertion type is the generic extension point using a URI-formatted assertion type (which does not require a registry). I would rather limit the ability to extend the two endpoints beyond their current architecture, and instead, allow others to specify new endpoints (e.g. a device endpoint for getting an authorization code without using browser redirection) that work in addition to the token endpoint (using an existing grant type or assertion). > We would want IANA to register them and then we need to list under what > conditions new profiles can be added, or existing onces updated/deleted. > RFC 5226 defines some typical policies, see > http://tools.ietf.org/html/rfc5226. > We probably want the policy "RFC Required". When people write new > profiles we want them to provide a description about the use case, maybe an > example, we want them to discuss security, and we definitely want to > ensure that the overall write is consistent with the base specification (such > as > with the registry parameters it defines). The reviews would ensure that > existing profile do not in fact already provide the functionality of the newly > defined profile. Note that "RFC Required" > does not require a Standards Track RFC; an Informational or an Experimental > RFC is already sufficient. Those are less difficult to get published but they > still > provide a stable reference. I think Specification Required is better for most registries. > - Error Codes > > The document lists error codes in Section 3.1 and Section 4.3. I suspect that > they are not from the same pool of error codes. > > My question is whether some of the error codes are very specific to the > profiles themselves or rather generic in nature. I'm working to clean up errors in -09. > - Grant Type > > The Grant Type (grant_type) is described in Section 4. Currently, there are 5 > values defines ("authorization_code", "user_basic_credentials", "assertion", > "refresh_token", "none") and I assume that the list should be extensible > (even though the text currently says something else at the moment). > > Are there specific requirements that must be met in order to register new > grant types? I would rather not allow for new grant types. I think the assertion type offers as much extensibility as needed. However, I am going to propose we allow extension parameters to both endpoints. > - Assertion Type > > Section 4.1.3 defines the assertion type ("assertion_type"). The text > indicates that the content is an absolute URI and as such it is a bit > different to > the other value encodings we have seen previously. > Nevertheless, the question is whether some folks want to write > standardized templates for assertions, such as a specific form of SAML > assertion. This could help interoperability a lot, I believe. The solution is > still > to have a URI but to define an IANA managed space for IETF standardized > assertion types. Such a style is btw common. I am not sure this is needed. URIs provide name collision protection. Beyond that, people should write specs as needed. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
