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). 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 would argue that we do not want new profiles to update existing onces (unless they just informative changes or clarifications), in the sense that they use the same profile name but with a modified semantic. Instead, an updated profile would still define a new profile name and would as such be different. I believe depreciating an existing entry makes sense while deleting one does not. An open question might be whether there is a possibility for an extension (other than a new profile) to define an optional parameter that may get used with an existing profile. Note that at the moment there is no registry for parameters. - Scope The scope parameter is used in various places throught the document, such as Section 3. Currently, the description does not indicate whether there is a plan to have some standardized parameters with well-defined semantic. Here is the current text for the scope parameter: " scope OPTIONAL. The scope of the access request expressed as a list of space-delimited strings. The value of the "scope" parameter is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. " Do folks think it would be useful to have standardized values? If the answer is "yes", then it would be useful to differentiate the standardized values from those values that are purely defined locally by the authorization server. - 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. - 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? - 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. Do I miss something else? Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
