But that's so much work. :-P The ease of using a throwaway signed URL as a self-contained information unit shouldn't be ignored. It requires exactly zero client-side code and can survive all kinds of HTML repackaging and transit easily.
-- Justin On Mon, 2011-05-09 at 22:11 -0400, Peter Wolanin wrote: > What about using the cookie header? > > We have a sha1-HMAC authentication scheme where we are passing the > HMAC, nonce, timestamp as parts of the cookie header since scripting > languages that cannot access arbitrary headers still usually can > access this header. > > -Peter > > On Mon, May 9, 2011 at 3:34 PM, Justin Richer <jric...@mitre.org> wrote: > > I would still like to see a binding of this to use query or form parameters. > > I have a direct use case for handing out signed URLs to the client, for > > which we're using the OAuth 1.0 signing mechanism without tokens today. I'd > > love to switch to something that we could bind to OAuth2, but the > > restriction of using the Auth header puts the MAC token out of reach for my > > immediate usecase. > > > > -- Justin > > > > On 5/9/2011 3:22 PM, Eran Hammer-Lahav wrote: > > > > (Please discuss this draft on the Apps-Discuss <apps-disc...@ietf.org> > > mailing list) > > > > > > > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > > > > > The draft includes: > > > > > > > > * An HTTP authentication scheme using a MAC algorithm to authenticate > > requests (via a pre-arranged MAC key). > > > > * An extension to the Set-Cookie header, providing a method for associating > > a MAC key with a session cookie. > > > > * An OAuth 2.0 binding, providing a method of returning MAC credentials as > > an access token. > > > > > > > > Some background: OAuth 1.0 introduced an HTTP authentication scheme using > > HMAC for authenticating an HTTP request with partial cryptographic > > protection of the HTTP request (namely, the request URI, host, and port). > > The OAuth 1.0 scheme was designed for delegation-based use cases, but is > > widely “abused” for simple client-server authentication (the poorly named > > ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 > > and has been reintroduced as a standalone, generally applicable HTTP > > authentication scheme called MAC. > > > > > > > > Comments and feedback is 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
