On Sun, Dec 5, 2010 at 10:34 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > This is not how most HTTP authentication frameworks work (that was the > conclusion from my HTTP Token scheme proposal a year ago). Most frameworks > rather switch on the scheme name, not on a parameter inside the header.
The alternative, as suggested by James, requires a new scheme for each token type. My guess is that we will have quite a few types pretty soon: - bearer opaque - bearer transparent (JSON, signed by authz server) - JWT signed - MAC - etc. Who controls the auth header scheme names? Aren't we asking for a collision here? Marius > > EHL > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Marius Scurtescu > Sent: Friday, December 03, 2010 4:27 PM > To: Manger, James H > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > > 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 > > Marius > > > > On Thu, Dec 2, 2010 at 7:59 PM, Manger, James H > <james.h.man...@team.telstra.com> wrote: >> Eran, >> >>> What does scheme=basic mean [in a token response]? >> >> It means this token response contains credentials that can be used with the >> HTTP BASIC authentication scheme. Don't try to use the credentials with any >> other scheme. The access_token value would be used as the user-id, and the >> token_secret value as the password. >> >> >>> I think tying type and scheme together is less intuitive then letting >>> the type definition provide the right scheme(s). >> >> Keeping them separate offers an additional degree of indirection. >> Indirection is sometimes useful, but I don't think it adds any value here. >> It just means we need another registry (of token_types, with associated >> procedures); and we need an extra spec for each authentication mechanism to >> define the linkage to OAuth2. >> >> A lot of authentication mechanisms take similar inputs (an id and a secret) >> so they shouldn't each need a separate spec to define their binding to >> OAuth2. >> >> >>> I am using 'MAC' for my draft. >> >> As the token_type? As the HTTP authentication scheme? I hope both. >> >>> But its still an OAuth2 extension, not a completely generic HTTP scheme. >> >> I guess it is an OAuth2 extension in as much as it defines how to get MAC >> credentials from an OAuth2 token response: check token_type=MAC; >> access_token is the id; token_secret is the MAC key; mac_algorithm is the >> MAC algorithm. >> >>> It can be used independent of OAuth2 if you somehow got a token, >>> secret, and mac algorithm name. >> >> Hopefully you define a "WWW-Authenticate: MAC ..." response header that can >> list acceptable MAC algorithms. >> I think an OAuth2 token response for a MAC scheme should contain the same >> information as the WWW-Authenticate response header for the MAC scheme, plus >> the credentials to use (id & secret) and the OAuth2-specific lifetime >> management bits (eg how/when to refresh). We should explicitly define (in >> core) how to put a WWW-Authenticate header into a token response. >> >> -- >> James Manger >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
