On Sun, Dec 5, 2010 at 3:27 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > Marius, > >> How about: >> - keeping the scheme "OAuth2", for both WWW-Authenticate and Authorization >> - define both as name/value pairs (WWW-Authenticate is already) >> - require that one of the pairs be "type=<token-type>" >> >> For example: >> WWW-Authenticate: OAuth2 type=bearer >> Authorization: OAuth2 token=vF9dft4qmT, type=bearer > > > What is the benefit of trying to couple one form of bearer token so strongly > to the OAuth2 delegation flows? > You have now complicated the Authorization header (extra type=bearer param), > and the WWW-Authentication header (now indicates that delegation is > available, swapping-permanent-cred-for-temp-token is available, and bearer > authentication is required -- I hope a client can work out which is relevant > in any response).
Not sure the Authorization header is that more complicated. Name/value pairs are pretty straight forward and any client or server must be able to handle them. If anything, the Basic scheme type seems the odd one to me. > Should Eran's MAC mechanim also use the same scheme, just with type=mac and > adding its own parameters? I hope not. That's what I was suggesting. Why not? > We end up with multiple specs (core, bearer, MAC, any other auth > mechanism...) all adding bits to the same HTTP scheme -- and not just > registering their own "type" value, but also all their own parameters (eg > alg, nonce?, token...). This causes unnecessary complications, because it is > unnecessary tight coupling. I don't see where the complication is coming from. They all share the scheme and a 'type' parameter, the rest is type specific. >> WWW-Authenticate: OAuth2 type=bearer > > What does this mean to a client app? > Does it mean that if the client app already has a bearer token it should > repeat the request with that token. > Does it mean the client app should do an OAuth2 flow (which?) and expect a > bearer token? Does this type value override any type information in a > subsequent token response? That could be dangerous. Should a server include > multiple "WWW-Authenticate: OAuth2" headers if it can issue tokens for > different authentication mechanisms depending on > resources/scopes/client-app-preferences? > > "Authorization: BEARER ..." avoids a lot of confusion. Maybe, but how many schemes are we going to generate? Who controls these scheme names? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
