Right -- if you substitute "token" with "client id" and "token secret" with "client secret", then you've got the makings for 2-legged OAuth 2.0 right there. I think you should call out that use case explicitly in your draft.
-- Justin ________________________________________ From: Eran Hammer-Lahav [[email protected]] Sent: Sunday, January 09, 2011 3:39 PM To: Richer, Justin P.; OAuth WG Subject: RE: OAuth MAC token type draft Well, you need the token as the identifier of the secret being used. So if you think of a token as an 'id', then it works as is. EHL > -----Original Message----- > From: Richer, Justin P. [mailto:[email protected]] > Sent: Sunday, January 09, 2011 11:47 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: OAuth MAC token type draft > > I'd like to see a way to use this mechanism without tokens -- that is, the > traditional two-legged signed-http-fetch approach. Maybe have the spec > here give details of a method using pre-shared client secrets instead of > OAuth tokens would be all it'd take. > > -- Justin > > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Eran > Hammer-Lahav [[email protected]] > Sent: Sunday, January 09, 2011 12:18 PM > To: OAuth WG > Subject: [OAUTH-WG] OAuth MAC token type draft > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. > > No body signature support yet, but will add that in -01. > > EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
