Mike Jones,


Thanks for writing draft-ietf-oauth-v2-bearer-01.

I feel there are some major problems with this draft, though.

Primarily, it is bound so tightly to OAuth2 core that it misses the point (& 
benefit) of separating the specs.



This draft re-uses the "OAuth2" HTTP authentication scheme name. It uses it to 
transmit a bearer token from a client app to a web server. This scheme name is 
already used by the core spec (draft-ietf-oauth-v2). The core spec uses it to 
indicate when a client needs to do a 
delegation/get-a-token/swap-longterm-cred-for-shortterm-cred flow (and 
hopefully in the future it will indicate the URIs for doing those flows). These 
core & bearer uses are quite different. They are different enough that 
different scheme names need to be used.



The reason the bearer draft almost gets away with re-using OAuth2 is that is 
only defines an "Authorization: OAuth2 ..." header, while the core spec only 
defines an "WWW-Authenticate: OAuth2 ..." header so the clash isn't obvious. 
However, the bearer draft could (and should) usefully define a WWW-Authenticate 
response header. For instance, such a header could indicate whether or not the 
server supports bearer tokens in URI query parameters, and/or in the body. At 
the moment a server MAY support these, with no nice way for a client app to 
tell.



Splitting the OAuth2 document recognised that OAuth2 delegation flows can 
deliver credentials for different authentication schemes - so one such 
authentication scheme should not hijack the OAuth2 name.





--

James Manger



_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to