There is no reason to overload the realm with new meanings. It
is well defined already in 2617.
If we decide to support a discovery method using an external
document (XRD, etc.), it should be expressed using a Link header not inside the
auth header.
EHL
From: Justin Hart
[mailto:onyxraven at gmail.com]
Sent: Friday, October 02, 2009 11:13 AM
To: Eran Hammer-Lahav
Cc: Brian Eaton; oauth at ietf.org
Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
In the discovery-sense, could
realm define the URL to the discovery document, which would then define the
complex validity-realm information as well as all the appropriate endpoints,
etc? Seems like building that in could help solve any 'magic' url in the
discovery phase. Seems like a reasonable use of the parameter.
On Fri, Oct 2, 2009 at 11:12 AM, Eran Hammer-Lahav <eran at hueniverse.com> wrote:
In the case of Basic, it is very useful for UI optimization
and I think that can translate to OAuth as well. The browser knows it already
asked the user for credentials for a given realm and can simply reuse them
without having to ask for it again. However, the browsers today look for other
bits of information to make sure an evil domain doesn't pretend to have the
realm of a good domain, etc.
Also, I think I skipped your comment about why we need a new scheme name (to
replace 'OAuth'). I don't want to use the oauth_version parameter but still
need a super simple way for clients to figure out that this is another version.
It also means that old clients will not try to do something stupid with the
wrong OAuth challenge because they don't look at the version.
The version parameter was poorly defined and does not provide enough clarity to
reuse the same scheme name.
EHL
> -----Original Message-----
> From: Brian Eaton [mailto:beaton at google.com]
> Sent: Friday, October 02, 2009 9:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth at ietf.org
> Subject: Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token
>
> On Thu, Oct 1, 2009 at 6:31 PM, Eran Hammer-Lahav <eran at hueniverse.com>
> wrote:
> >> Should probably drop "realm" unless we can define the
semantics. (I
> >> can't.)
> >
> > I think 2617 defines realm pretty well. It is a URI string that
> identifies the
> > set of resources accessible with a given credential. If you feel we
> need to
> > spell out the lessons (restrictions) learned from Basic, we can look
> into that.
>
> Except that the mapping from "URI string" to "set of
resources" bit
> doesn't actually work in practice. The mappings either tend to be
> trivial (in which case realm is unnecessary) or complex (in which case
> realm doesn't have a syntax rich enough to describe the problem.)
>
> I can't prove that realm is useless, but I'm pretty sure that if you
> give me a dozen examples of possible semantics for "realm" I can
break
> all of them. =)
>
> >> I think that the ABNF should probably just be the prefix,
followed
> by
> >> name-value pairs. I don't see a reason to have a separate
sub-
> scheme.
> >
> > Why define a parameter when it is clearly a sub-scheme? I makes
> client much
> > simpler by being able to look for the first two words in the header
> and known what is going on.
> > Otherwise we need to define a certain order for parameters which is
> ugly.
>
> Or we can have clients that know to look at the "Token" scheme
and
> then parse the rest of the header as name/value pairs. There is no
> need to define parameter ordering.
>
> >> WWW-Authenticate: Token <json>
> >
> > That's crazy talk.
>
> OK. =)
>
> >> That said, RSA might only get used when requesting access tokens,
> not
> >> when using them. There is no RSA private key associated
with an
> >> access token, so it's kind of hard to use it. =)
> >
> > Then we need to define how it works in the context of authentication.
> Keep in mind that this is
> > ONLY for accessing protected resources once a token has been
> obtained. We will deal
> > with obtaining tokens separately and there we can include PK support
> as part of the
> > client credentials package.
>
> OK, that makes sense.
>
> Cheers,
> Brian
_______________________________________________
OAuth mailing list
OAuth at ietf.org
https://www.ietf.org/mailman/listinfo/oauth
|