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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth