> -----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.