Thanks Hannes On Feb 12, 2013, at 12:06 PM, Hannes Tschofenig wrote:
> 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. but why do not we hit this same issue in the JWS case? In this situation there is as well a key for sign... And AS and RS can be as well two different entities... Regards Antonio > > 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 t hen >>> 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
