[OAUTH-WG] Extensibility for OAuth?

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

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