Re: [OAUTH-WG] Proposal for a New 2617 Scheme: Token

[Justin Hart <onyxraven at gmail.com>]

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