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). Should Eran's MAC mechanim also use the same scheme, just with type=mac and adding its own parameters? I hope 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. > 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. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
