> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Monday, December 06, 2010 11:57 AM > To: Eran Hammer-Lahav > Cc: Manger, James H; [email protected] > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > > On Sun, Dec 5, 2010 at 10:34 PM, Eran Hammer-Lahav > <[email protected]> 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?
Nah. It's a proposed registry and has never been very active. EHL > Marius > > > > > > EHL > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Marius Scurtescu > > Sent: Friday, December 03, 2010 4:27 PM > > To: Manger, James H > > Cc: [email protected] > > 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 > <[email protected]> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
