> -----Original Message----- > From: Manger, James H [mailto:[email protected]] > Sent: Wednesday, February 03, 2010 3:23 PM > To: Eran Hammer-Lahav; OAuth WG ([email protected]) > Subject: RE: Token Access Authentication Scheme Draft > > > 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.
It doesn't. > 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". This is exactly what the current draft proposes, as long as these statements are "said" by the server when issuing the credentials, not when sending a 401 response. All the spec is doing in that regard is giving these statements a common language to enable interop for a few methods. EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
