The transport of the session key from the authorization server is described in Section 5.1 and is called "mac_key".
The mechanism to transport the session key from the authorization server to the resource server is not yet described in the document. This has historical reasons: OAuth 1.0 did not separate the authorization server from the resource server in the way OAuth 2.0 does. Ciao Hannes On Feb 12, 2013, at 12:28 PM, Antonio Sanso wrote: > 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 th en >> 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
