comments below... On Feb 4, 2011, at 6:22 AM, Manger, James H wrote:
> Comments on draft-hammer-oauth-v2-mac-token-02 > <http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02> > > This draft is a good improvement. > > (continuing numbering from my previous comments) > > 11. The "access token" field would be better labelled "id". The MAC scheme > only needs this field to identify the MAC secret. The MAC scheme itself > doesn't need to care whether this id also represents a scope, duration, > assertion etc. > > Though it may slightly complicated the use of the MAC scheme with OAuth2, > I would seriously consider supporting two identifiers: > * An authentication id -- to identify the key used to verify the MAC; and > * An authorization id -- to identify the scope/account/permissions/duration... > that the client want to act under. > The SASL framework has these two concepts > [RFC4422 Simple Authentication and Security Layer (SASL)]. > Any modern SASL authentication mechanism will be expected to support both ids. > The authorization id is a good match for an OAuth2 token or other sort of > assertion. > The OAuth2-to-MAC binding could define a 'keyid' parameter to accompany the > 'secret'. > The 'keyid' value would map to the authentication id field in the MAC scheme, > and the 'access_token' would map to the authorization id field. While I don't see much need for two IDs (they could be combined in the token, if necessary, as Eran mentions) I do favor using a term other than token, merely for the sake of clarity when this is used outside of OAuth. Consistent naming with other similar conventions (AWS, SASL?, etc.) seems like a logical decision maker. I had suggested "assertion" as each token seems to be asserting some identity, permission, etc. However, "id" is perhaps just as good if only to remove the implication that this is to be used primarily with OAuth or that the value of "token" is always a value so-named coming from an OAuth server. > > 13. The MAC algorithm should be explicitly indicated in the request, instead > of being implied by the access-token/id. I suggest including an "algorithm" > parameter in the "Authorization" request header. I also suggest including an > "algorithms" parameter in the "WWW-Authenticate" response header that is a > (comma-separated?) list of MAC algorithms that the server supports. After seeing James' follow-up on this, I see the value to implementors and tiered architectures to adding this parameter. On the other-hand, this could be yet another element forced into "token" (as with client_id) if it was critical for providers to detect at the header. This seems to be a tension between minimalism and convention. One argument for not including it is that providers should not be tempted to validate a token based on the signature method supplied by the client. That is, if "algorithm" was included, the provider MUST validate at the lower level that it matches that of the token issued. By not having it in the header, providers are required to do the look-up. As Eran said, it's not negotiable. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
