HI,
On 15/02/13 18:29, William Mills wrote:
At this point I am more in favor converting the MAC token format to JWT
and getting the signature envelope added that way. It's really a matter
of time.
MAC stalled because folks see the HOK tokens as a replacement.
It's also been a matter of Justin and I having the time to take it up again.
Sure, thanks for the above info, as I've said before I'm ultimately fine
with having MAC supported just in our implementation for example, and
let those users who decide to use know that they actually write a
compliant OAuth2 code - but not inter-operable unless some other stack
does it too...Interoperability may not be highly important in some cases
too, so...
Ultimately whatever the experts decide upon will be good I guess, the
question will remain though if dropping MAC will help with avoiding
having N- number of OAuth(s) variants - it appears the sentiment is
quite strong in oAuth1 community toward this style MAC kind of replicates.
Thanks, Sergey
------------------------------------------------------------------------
*From:* Sergey Beryozkin <sberyoz...@gmail.com>
*To:* oauth@ietf.org
*Sent:* Friday, February 15, 2013 8:25 AM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
Call - 11th February 2013
I wonder why it is proving so difficult to get a nearly completed MAC
draft completed ?
Is it because:
1. JWT was first in OAuth2 and thus it wins ?
2. MAC is not 'capable' enough as JWT is ?
3. Not enough motivation for some vendors to push MAC ?
Example, in cases where not a product but a development framework is
shipped (as with us for example), IMHO is it a big motivation to get MAC
done for the reasons repeated many times. Or in case of migrating Flickr
users to OAuth2.
I think I can see why no interest is there where nothing is really
achieved if JWT is used from the get go, no particular need to get OAuth
1.0 developers out there migrating to the particular products.
This is 3. Re 2, I think there was enough expressed to suggest that it
can complement JWT nicely. So far I'm inclined to think it is 3. and 2.
which stop it from being completed, with 3. 'contributing' indirectly
but significantly,
Just my 2c
Thanks, Sergey
On 15/02/13 16:09, William Mills 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
<mailto:tors...@lodderstedt.net>>
> *To:* William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>>
> *Cc:* Mike Jones <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>; Justin Richer
> <jric...@mitre.org <mailto:jric...@mitre.org>>; Phil Hunt
<phil.h...@oracle.com <mailto:phil.h...@oracle.com>>; IETF oauth WG
> <oauth@ietf.org <mailto: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
<mailto:wmills_92...@yahoo.com>
> <mailto:wmills_92...@yahoo.com <mailto: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
<mailto:tors...@lodderstedt.net>
>> <mailto:tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>>>
>> *To:* William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>
>> <mailto:wmills_92...@yahoo.com <mailto:wmills_92...@yahoo.com>>>
>> *Cc:* Mike Jones <michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>
>> <mailto:michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>>; Justin Richer
>> <jric...@mitre.org <mailto:jric...@mitre.org>
<mailto:jric...@mitre.org <mailto:jric...@mitre.org>>>; Phil Hunt
>> <phil.h...@oracle.com <mailto:phil.h...@oracle.com>
<mailto:phil.h...@oracle.com <mailto:phil.h...@oracle.com>>>; IETF oauth WG
>> <oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org
<mailto: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
<mailto:wmills_92...@yahoo.com>
>> <mailto:wmills_92...@yahoo.com <mailto: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
<mailto:michael.jo...@microsoft.com>
>>> <mailto:michael.jo...@microsoft.com
<mailto:michael.jo...@microsoft.com>>>
>>> *To:* Justin Richer <jric...@mitre.org <mailto:jric...@mitre.org>
<mailto:jric...@mitre.org <mailto:jric...@mitre.org>>>;
>>> Phil Hunt <phil.h...@oracle.com <mailto:phil.h...@oracle.com>
<mailto:phil.h...@oracle.com <mailto:phil.h...@oracle.com>>>
>>> *Cc:* IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>
<mailto:oauth@ietf.org <mailto: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>
<mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>>
>>> [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
<mailto: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 <http://www.independentid.com/>
>>> > phil.h...@oracle.com <mailto:phil.h...@oracle.com>
<mailto:phil.h...@oracle.com <mailto: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 <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
<mailto:OAuth@ietf.org>>
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
<mailto:OAuth@ietf.org>>
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
<mailto:OAuth@ietf.org>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
<mailto:OAuth@ietf.org>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org
<mailto:OAuth@ietf.org>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
