Because we're goign to want a single implementation, not N.
________________________________
From: Tim Bray <twb...@google.com>
To: William Mills <wmills_92...@yahoo.com>
Cc: Torsten Lodderstedt <tors...@lodderstedt.net>; IETF oauth WG
<oauth@ietf.org>
Sent: Friday, February 15, 2013 8:49 AM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call -
11th February 2013
Not deeply acquainted with the Flickr scenario, but it occurs to me to ask: If
OAuth 1.0 is working well for them, why don’t they just keep using it? I.e. if
there’s already a good solution in place for people who require secure
authn/authz over insecure channels, why would we go the extra work of
duplicating that in OAuth 2 territory? -T
On Fri, Feb 15, 2013 at 8:09 AM, William Mills <wmills_92...@yahoo.com> wrote:
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
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
