I'm in favor of reusing the JWT work that this WG is also doing. :-)
I'm pretty skeptical of us inventing another custom scheme for signing HTTP
headers. That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved
in the first place.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
That's my reading of it as well, Phil, thanks for providing the clarification.
One motivator behind using a JSON-based token is to be able to re-use some of
the great work that the JOSE group is doing but apply it to an HTTP payload.
What neither of us want is a token type that requires stuffing all query,
header, and other parameters *into* the JSON object itself, which would be a
more SOAPy approach.
-- Justin
On 02/12/2013 12:30 PM, Phil Hunt wrote:
> 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 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
