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.