[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.