Clarification. I think Justin and I were in agreement that we don't want to see a format that requires JSON payloads. We are both interested in a JSON token used in the authorization header that could be based on a computed signature of some combination of http headers and body if possible.
Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote: > 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 then 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
