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

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



> -----Original Message-----
> From: Brian Eaton [mailto:beaton at google.com]
> Sent: Thursday, October 01, 2009 4:44 PM


> 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.
 
> 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.
 
> Out of curiosity, what would people think if instead of defining
> yet-another-serialization-format, we used JSON for this, e.g.
> 
> WWW-Authenticate: Token <json>

That's crazy talk.
 
> RSA is important.  Public key crypto is a building block we shouldn't
> leave out.  Not having it means we can't ever do any kind of automatic
> consumer discovery.
> 
> 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.

EHL

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