Each scheme will have an RFC and will get proper review. If there is consensus for a new scheme, the rest doesn't matter. And being able to reuse these schemes without having to use a confusing OAuth2 scheme is a big benefit.
EHL > -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Monday, December 06, 2010 12:47 PM > To: Eran Hammer-Lahav > Cc: Manger, James H; [email protected] > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 > > On Mon, Dec 6, 2010 at 12:43 PM, Eran Hammer-Lahav > <[email protected]> wrote: > > > > > >> -----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. > > Doesn't that mean that we should be even more cautious with creating lots > of schemes? > > Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
