> The reason why it makes little sense to have different schemes for > different types of tokens is that it is not the protected resource's > job to say which algorithm should be used, but the server when issuing > the token for that resource. The draft did a poor job at separating the > role of the server issuing the tokens from the role of the server > providing access to resources.
It is not the role of a spec for an HTTP authentication mechanism to make assumptions about how credentials are issued, or assumptions about what additional authentication mechanisms might be supported by any particular server. I hope a HTTP request-signing spec does not need to assume that a separate security server is involved to do all possible mechanism negotiation. I am very happy for a security server to say: eg "use this token+secret with HMAC-SHA256 at http://api.example.org/ for 10 minutes" A security server may want to be a little less specific: eg "use this token+secret with any MAC algorithm at http://*.example.com/"; Or eg "use this token+secret with the OAuth MAC algs or draft-oiwa-http-mutualauth at xyz". A statement from a security server binding a token+secret to "1 or more 'mechanisms' of the 'Token' scheme" is no easier than a statement binding then to "1 or more 'schemes'", Binding to 'mechanisms' of the 'Token' scheme is significantly worse as it exclude a whole swag of current and future authentication mechanisms that are not written with OAuth specifically in mind. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
