This is excellent. Thanks for pulling together a signature-based token spec. Some feedback:
- As I think was mentioned in a previous post, this spec is also attractive as method for asserting client credentials (eg, for access token requests). Your point is noted on substituting "client_id" as "token" though some language to recommend the general application of this field could be helpful for those reading the spec to draw the same conclusion. My personal preference might be the use of the word "assertion" over "token" if this is meant to be a general-purpose mechanism. Otherwise, people will naturally draw a strong correlation between related OAuth specs. I suppose this is the same sort of tension involved in keeping a more general name of MAC or assuming a more integral term, OAUTH_MAC. In any case, it feels like a "hack" to ask developers to put "client_id" into the "token" field, so I prefer multi-purpose names where multiple uses are intended. - When presenting an MAC token, it would be attractive if client credentials could also be captured in the assertion without relying on a separate assertion (imagine the confusion in two Authorization headers, MAC [token=client_id] and MAC [token=token]). A simple solution (and one that preserves the same double-secret signature as OAuth 1.0) would be to require the value of "secret" (used as the signing key) to be a concatenation of client_secret and token_secret. I assume this kind of special instruction could be made by providers just as simply as the explanation of the use of "token" for client_id in client auth. I mention it to see if anyone sees conflicts or objections to this use, or if it is worth including the option in the spec in some manner. If the spec is trying to remain more independent from the core OAuth spec, then I suppose that's a reason to both allow such alternate use and not address it. If the spec means to address common use cases and draw tight corr elation between the two specs, then I see this as an positive clarification. Validating client identity on the presentation of tokens is a valuable ability. Using client credentials in the assertion allows for the signature to include an element that is potentially never sent over the wire or in a previous OAuth exchange. - Using a body hash and making it optional is a great alternative to the OAuth 1.0a method incorporating content body params. Given the confusion that parameter ordering and sorting caused for 1.0a why not apply the same method for query-string parameters? That is, normalize the query-string parameters, sort them, create a parameter hash, and include it in the assertion (optional). This allows providers to not require this if they consider it to be unnecessary for security as well as a hurdle to message signing. In any case, I'd see both elements as either optional or required. - As expressed, I had concerns over versioning of the format as any modification could introduce brittleness to the construction of the Signature Base String. Your preference seems to be to introduce MAC2 if incompatibility or confusion arises. Assuming everyone else is fine with that, it's an acceptable path forward. Of all these points, I'm most interested in feedback from others on the use of client_secret+token_secret as option for the signature key. skylar On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > > New version includes the following changes: > > o Added body-hash support. > o Updated OAuth 2.0 reference to -12 and added token type registration > template. > o Removed error and error URI attributes (codes were just a duplication > of the HTTP status codes). > > Feedback would be greatly appreciated. > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
