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.
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
