Hi Hannes, how this session key "differs" from the key described in the current draft [0]?
Thanks and regards Antonio [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02 On Feb 12, 2013, at 10:44 AM, Hannes Tschofenig wrote: > Hi Bill, > > On Feb 12, 2013, at 11:27 AM, William Mills wrote: > >> Is key distribution how AS and PR share keys for token >> encryption/decryption or specifically about the keys for the HOK tokens? >> > In order for the client to compute the keyed message digest it needs to have > the session key. This session key is sent from the authorization server to > the client and everyone on the call agreed that this has to be standardized. > > The resource server who receives the message from the client also needs to > have the session key to verify the message. How the resource server obtains > this session key was subject for some discussion on the call. I presented > three different ways of how the resource server is able to obtain that key. > We have to decide on one mandatory-to-implement mechanism. The open issue is > which one? > >> For the MAC token spec, I don't actually care whether we use JSON or now, >> but I'm in full agreement that we do NOT duplicate any HTTP info into the >> JSON. Just signatures of that stuff. >> > I believe the folks on the call also agreed with you on that aspect that the > content of the HTTP message should not be replicated in the JSON payload > itself. > > Ciao > Hannes > >> From: Hannes Tschofenig <hannes.tschofe...@gmx.net> >> To: IETF oauth WG <oauth@ietf.org> >> Sent: Tuesday, February 12, 2013 1:10 AM >> Subject: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - >> 11th February 2013 >> >> Here are my notes. >> >> Participants: >> >> * John Bradley >> * Derek Atkins >> * Phil Hunt >> * Prateek Mishra >> * Hannes Tschofenig >> * Mike Jones >> * Antonio Sanso >> * Justin Richer >> >> Notes: >> >> My slides are available here: >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt >> >> Slide #2 summarizes earlier discussions during the conference calls. >> >> -- HTTP vs. JSON >> >> Phil noted that he does not like to use the MAC Token draft as a starting >> point because it does not re-use any of the work done in the JOSE working >> group and in particular all the libraries that are available today. He >> mentioned that earlier attempts to write the MAC Token code lead to problems >> for implementers. >> >> Justin responded that he does not agree with using JSON as a transport >> mechanism since this would replicate a SOAP style. >> >> Phil noted that he wants to send JSON but the signature shall be computed >> over the HTTP header field. >> >> -- Flexibility for the keyed message digest computation >> >> From earlier discussion it was clear that the conference call participants >> wanted more flexibility regarding the keyed message digest computation. For >> this purpose Hannes presented the DKIM based approach, which allows >> selective header fields to be included in the digest. This is shown in slide >> #4. >> >> After some discussion the conference call participants thought that this >> would meet their needs. Further investigations would still be useful to >> determine the degree of failed HMAC calculations due to HTTP proxies >> modifying the content. >> >> -- Key Distribution >> >> Hannes presented the open issue regarding the choice of key distribution. >> Slides #6-#8 present three techniques and Hannes asked for feedback >> regarding the preferred style. Justin and others didn't see the need to >> decide on one mechanism - they wanted to keep the choice open. Derek >> indicated that this will not be an acceptable approach. Since the resource >> server and the authorization server may, in the OAuth 2.0 framework, be >> entities produced by different vendors there is an interoperability need. >> Justin responded that he disagrees and that the resource server needs to >> understand the access token and referred to the recent draft submission for >> the token introspection endpoint. Derek indicated that the resource server >> has to understand the content of the access token and the token >> introspection endpoint just pushes the problem around: the resource server >> has to send the access token to the authorization server and then the >> resource server gets the result back (which he the n > a >> gain needs to understand) in order to make a meaningful authorization >> decision. >> >> Everyone agreed that the client must receive the session key from the >> authorization server and that this approach has to be standardized. It was >> also agreed that this is a common approach among all three key distribution >> mechanisms. >> >> Hannes asked the participants to think about their preference. >> >> The questions regarding key naming and the indication for the intended >> resource server the client wants to talk to have been postponed. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
