I'll repeat the use case for Flickr, which requires OAuth 1.0a type capabilites
that OAuth 2 does not provide. Simply stating "move to HTTPS" is not a viable
response here.
________________________________
From: Torsten Lodderstedt <tors...@lodderstedt.net>
To: William Mills <wmills_92...@yahoo.com>
Cc: Mike Jones <michael.jo...@microsoft.com>; Justin Richer
<jric...@mitre.org>; Phil Hunt <phil.h...@oracle.com>; IETF oauth WG
<oauth@ietf.org>
Sent: Friday, February 15, 2013 7:22 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Hi Bill,
I think one needs to compare the costs/impact of HTTPS on one side and the
implementation of integrity protection and replay detection on the other. We
had this discussion several times.
regards,
Torsten.
Am 15.02.2013 um 08:08 schrieb William Mills <wmills_92...@yahoo.com>:
I fundamentally disagree with that too. OAuth 2 is the *framework*, one which
supports multiple token types. Bearer tokens were the first credential type
defined.
>
>
>OAuth 1.0a also requires HTTPS transport for authentication and getting the
>token.
>
>
>There are real use cases for tokens usable over plain text with integrity
>protection.
>
>
>-bill
>
>
>
>________________________________
> From: Torsten Lodderstedt <tors...@lodderstedt.net>
>To: William Mills <wmills_92...@yahoo.com>
>Cc: Mike Jones <michael.jo...@microsoft.com>; Justin Richer
><jric...@mitre.org>; Phil Hunt <phil.h...@oracle.com>; IETF oauth WG
><oauth@ietf.org>
>Sent: Thursday, February 14, 2013 10:05 PM
>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
>11th February 2013
>
>
>Hi Bill,
>
>
>OAuth 2.0 took a different direction by relying on HTTPS to provide the basic
>protection. So the need to have a token, which can be used for service
>requests over plain HTTP is arguable. My understanding of this activity was,
>the intend is to provide additional protection on top of HTTPS.
>
>
>regards,
>Torsten.
>
>Am 15.02.2013 um 02:31 schrieb William Mills <wmills_92...@yahoo.com>:
>
>
>I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0
>solved in the first place.", unless "solving" means does not address the need
>for it at all.
>>
>>
>>OAuth 2 does several good things, but it still lacks a defined token type
>>that is safe to user over plain text HTTP. 1.0a solved that.
>>
>>
>>
>>________________________________
>> From: Mike Jones <michael.jo...@microsoft.com>
>>To: Justin Richer <jric...@mitre.org>; Phil Hunt <phil.h...@oracle.com>
>>Cc: IETF oauth WG <oauth@ietf.org>
>>Sent: Thursday, February 14, 2013 1:44 PM
>>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
>>11th February 2013
>>
>>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
>>
>>
>>
>_______________________________________________
>>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
