Sounds great Eran,
> 1. Add a parameter to the token response to include an extensible token
> scheme.
Yes. I suggest a parameter named "scheme". The value can be an HTTP
authentication scheme name (eg "scheme":"BASIC") for which the response is
providing credentials. Not all possibilities are HTTP authentication schemes
but they can be assigned pseudo-HTTP-auth-scheme-names (eg "scheme":"TLS-PSK").
> The default (if omitted) will be whatever the bearer token scheme is called.
May as well include the bearer token scheme name (ie don't bother with a
default). Might even be convenient to use the scheme name as a JSON key in a
token response.
"credentials":{
"bearer":{"token":"54er"},
"basic":{"userid":"jim","password":"beer2"} }
> 2. Break the core specification into multiple parts.
Yes. Hopefully the "using a token" parts don't have to be OAuth-specific. They
might not even use the term "token". A signature spec could use an "id" and
"key", without caring whether or not those items came from a "getting a token"
response or from a config file.
> 3. Introduce two signature proposals in one or more documents, for the JSON
> token and 1.0a-like method.
Yes. Separate docs for each signature proposal sounds best to me.
> --- Benefits
>
> 2. Solve a few open issues:
>
> * The need to decide on discovery for the entire protocol (moves it to each
> scheme).
I don't think it removes much of the need for discovery.
Apps still need to discover that OAuth delegation can be used to access a
resource (and where to send the user). I suspect the token response performs
some of the discovery related to specific schemes (eg the response says "here
is a token to use with the 'BEARER' scheme", or "here is an id for this
delegation and a secret to used in signature scheme XYZ".
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
