OK.
So then the question is the right way to communicate token endpoints. Is it
cleaner/preferred to have everything in the WWW-Authenticate header, or to
break things out so we're not stuffing a lot into those headers and repeating
outselves? So, all in one would be:
WWW-Authenticate: MAC realm="somerealm"
token_url="http://login.example.com/token";
auth_url="http://login.example.com/webauth";
Broken out might be:
WWW-Authenticate: MAC realm="OAuth2"
Link: <http://login.example.com/token?grant_type=MAC> rel="oath2-token"
Link:
<http://login.example.com/auth?.done=http://foo.service.come/blahblahblah>
rel="oath2-auth"
-bill
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Saturday, February 05, 2011 10:21 AM
> To: William Mills
> Cc: Phil Hunt; OAuth WG
> Subject: Re: [OAUTH-WG] Bearer token type and scheme name (deadline:
> 2/10)
>
> that's not the way WWW-Authenticate headers are used today. Instead the
> resource server should return a single WWW-Authenticate header _per_
> supported authentication scheme, such as
>
> WWW-Authenticate: MAC realm="somerealm"
> WWW-Authenticate: BEARER realm="somerealm"
>
> furthermore, I think interdependencies among WWW-Authenticate headers
> as suggested by Phil
>
> WWW-Authenticate: OAuth
> token="MAC;BEARER",authorizationUrl="xxxxx",tokenUrl="yyyyy
>
> could be rather fragile.
>
> I would expect the WWW-Authenticate header to return all the data
> required to obtain the credentials/tokens, such as
>
> WWW-Authenticate: MAC realm="somerealm",
> tokenUrl="yyyyy&token_secret=yes"
> WWW-Authenticate: BEARER realm="somerealm", tokenUrl=""yyyyy"
>
> Which raises the question whether the coupling between authentication
> schemes and the OAuth2 core protocol is stronger than assumed.
>
> please als see http://www.ietf.org/mail-
> archive/web/oauth/current/msg04988.html
>
> regards,
> Torsten.
>
> Am 04.02.2011 22:39, schrieb William Mills:
>
> > 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:phil.h...@oracle.com]
> >> 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
> >> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
