I agree, that is still to be defined. There seems to be some push back on discovery, but this is likely warranted. If only because web sites may have both browser clients and app clients.
In a previous message, I did suggest the web site return HTTP 401 as below... >> 401 Unauthorized >> WWW-Authenticate: Basic realm="tokenSvc" >> WWW-Authenticate: Digest realm="tokenSvc" >> WWW-Authenticate: Form url="/clientAuthenticate.jsp",realm="tokenSvc" It could also include other items for "MAC", etc. The only other issue would be determining whether the token is obtained via an OAuth profile or via some default profile. That could be handled with something like: WWW-Authenticate: Basic realm="somerealm" WWW-Authenticate: MAC realm="somerealm" WWW-Authenticate: OAuth token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyyy" The above would suggest that MAC tokens could be used alone as described in some specification for "MAC". However, the presence of the OAuth header indicates that MAC and BEARER tokens can be used in the OAuth pattern. I think this allows both de-coupling of tokens from OAuth but also informs clients what tokens can be used with OAuth. There may be other ways to do this. But it does help with the decoupling. Phil phil.h...@oracle.com On 2011-02-04, at 11:44 AM, William Mills wrote: > I was thinking more about how the client knows what to use. The ubiquitous > "service documentation" may come in to play here. Some form of serv ice > discovery/webfinger thing could also be used. > >> -----Original Message----- >> From: Phil Hunt [mailto:phil.h...@oracle.com] >> Sent: Friday, February 04, 2011 11:37 AM >> To: William Mills >> Cc: Marius Scurtescu; OAuth WG >> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >> 2/10) >> >> Yes. This should be defined in each token type specification. >> >> Phil >> phil.h...@oracle.com >> >> >> >> >> On 2011-02-04, at 11:29 AM, William Mills wrote: >> >>> The only challenge is to know what scheme to use and what the nuances >> are of how to present the credential. >>> >>>> -----Original Message----- >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >> Behalf >>>> Of Phil Hunt >>>> Sent: Friday, February 04, 2011 9:42 AM >>>> To: Marius Scurtescu >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline: >>>> 2/10) >>>> >>>> OAuth should be able to support other token schemes. >>>> >>>> Or conversely you don't have to have OAuth to use MAC, JWT, or >>>> whatever. >>>> >>>> Phil >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote: >>>> >>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav >>>> <e...@hueniverse.com> wrote: >>>>>> Hey Marius, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marius Scurtescu [mailto:mscurte...@google.com] >>>>>>> Sent: Thursday, February 03, 2011 10:36 AM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG >>>>>>> Subject: Re: [OAUTH-WG] Bearer token type and scheme name >>>> (deadline: >>>>>>> 2/10) >>>>>>> >>>>>>> On Thu, Feb 3, 2011 at 12:34 AM, Eran Hammer-Lahav >>>>>>> <e...@hueniverse.com> wrote: >>>>>>> >>>>>>>> 2. Single OAuth2 scheme with sub-schemes >>>>>>>> >>>>>>>> Define a single authentication scheme for all token types with >>>> some >>>>>>>> attribute used to detect which scheme is actually being used. >>>>>>>> >>>>>>>> Benefits: >>>>>>>> >>>>>>>> - single scheme, reuse of the 1.0 pattern. >>>>>>>> >>>>>>>> Downsides: >>>>>>>> >>>>>>>> - requires a new registry for authentication header parameters. >>>>>>> >>>>>>> How is this different from option 1? Wouldn't that need some >>>> registry? >>>>>> >>>>>> #1 relies on the existing practice of creating HTTP scheme names >> (no >>>> current registry but httpbis might be creating one), as well as the >> -12 >>>> token type registry. Using a sub-scheme means you also need a >> registry >>>> for the header attributes that each token type will need (unless you >>>> just don't care about using the same attribute name for different >>>> needs). >>>>> >>>>> Sure, there is no registry for schemes yet, but we would still need >>>>> some coordination. The fact that a sub-scheme needs a registry that >>>> we >>>>> control is a benefit not a downside IMO. >>>>> >>>>> >>>>>>>> - schemes are not easily reusable outside OAuth. >>>>>>> >>>>>>> Sure. But I really don't see this group trying to create generic >>>> authentication >>>>>>> schemes. >>>>>> >>>>>> MAC is exactly that. >>>>> >>>>> May or may not be. My point is that this group is not focused on >>>>> creating generic authentication schemes. Are you aware of any other >>>>> protocols that might use MAC or BEARER? Are we willing to put in >> the >>>>> effort to create generic schemes? Is it our charter? >>>>> >>>>> >>>>>>>> - existing frameworks usually switch on scheme name, not on sub >>>>>>>> scheme, which will cause difficulty in some deployments. >>>>>>> >>>>>>> I can see this as a potential problem. But considering that there >>>> wasn't much >>>>>>> objection to use "OAuth" as a scheme name before (total overlap >>>> with >>>>>>> OAuth 1, and the suggested solution was to look for the signature >>>>>>> parameter) I don't see how this is suddenly an issue. >>>>>> >>>>>> There was pretty strong objection to reusing OAuth. >>>>> >>>>> Yes, because there was no sub-scheme nor version (and the grammar >> was >>>>> totally broken). Even so, lots of implementations went ahead and >> did >>>>> it. Were there any scheme switching issues we are aware of? >>>>> >>>>> >>>>>>> Do we have a concrete problem here or this is just theoretical? >>>>>> >>>>>> This came up during the review of draft-hammer-http-token-auth >> [1]. >>>> There was a long thread about it where people posted actual >> framework >>>> issues. >>>>>> >>>>>>>> - potential to produce a very complicated scheme once many sub >>>> schemes >>>>>>>> are added. >>>>>>> >>>>>>> Why? I would argue that this option actually produces more >> uniform >>>>>>> schemes because it forces all of them to be name/value pairs. >>>> Beyond >>>>>>> token_type everything is scheme specific. I really don't see what >>>> is very >>>>>>> complicate here. >>>>>> >>>>>> It is still a single scheme with many different sub-schemes, each >>>> with different key-value pairs that may have conflicting meaning. >> The >>>> way I look at it is that if I try to fully implement this mega >> scheme >>>> (which means all its sub-schemes), it will likely be a complicated >>>> task. On the other hand, if you split it across scheme name, we >> already >>>> have a well-established system in place to pick and choose HTTP >>>> authentication schemes. >>>>> >>>>> No one has to implement a mega scheme. All schemes must use >>>> name/value >>>>> pairs and that's where the common part stops. >>>>> >>>>> >>>>>>>> - requires its own discovery method for which schemes are >>>> supported. >>>>>>> >>>>>>> Why is this a downside only for this option? >>>>>> >>>>>> Because the other options get this for free by using the WWW- >>>> Authenticate header (since each scheme has a unique name). You can >> list >>>> multiple headers in the 401 response. >>>>> >>>>> I thought we dropped WWW-Authenticate. Why cannot WWW-Authenticate >>>>> work for sub-schemes as well? >>>>> >>>>> >>>>>> Should I record your vote for #2? >>>>> >>>>> #2 or #3 >>>>> >>>>> >>>>> Thanks, >>>>> Marius >>>>> _______________________________________________ >>>>> 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
