I was thinking along the lines of simply returning the HTTP Authorization
header schemes that are supported. In the OAuth 2 context that would be
WWW-Authenticate: 401 error="blah blah blah" auth_types="Bearer MAC
Basic"
The client has to be aware of the authentication scheme names.
-bill
> -----Original Message-----
> From: Phil Hunt [mailto:[email protected]]
> Sent: Friday, February 04, 2011 1:14 PM
> To: William Mills
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
> 2/10)
>
> 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
> [email protected]
>
>
>
>
> 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:[email protected]]
> >> 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
> >> [email protected]
> >>
> >>
> >>
> >>
> >> 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: [email protected] [mailto:[email protected]] 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
> >>>> [email protected]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 2011-02-04, at 9:39 AM, Marius Scurtescu wrote:
> >>>>
> >>>>> On Thu, Feb 3, 2011 at 11:39 AM, Eran Hammer-Lahav
> >>>> <[email protected]> wrote:
> >>>>>> Hey Marius,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Marius Scurtescu [mailto:[email protected]]
> >>>>>>> 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
> >>>>>>> <[email protected]> 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
> >>>>> [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
