Hi,
On 16/02/13 17:57, William Mills wrote:
The reason to support 1.0a tokens in 2 is simply to provide a migration
path when a site has 1.0a endpoint it wants to support.
I really like the idea of having a migration path, which is very
important to have, but IMHO this approach won't work. Appears to me that
having a MAC completed (whenever feasible of course) will work better,
it will be a statement of intent/invitation...
Cheers, Sergey
------------------------------------------------------------------------
*From:* Phil Hunt <phil.h...@oracle.com>
*To:* William Mills <wmills_92...@yahoo.com>
*Cc:* Justin Richer <jric...@mitre.org>; Tim Bray <twb...@google.com>;
IETF oauth WG <oauth@ietf.org>
*Sent:* Friday, February 15, 2013 11:22 PM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference
Call - 11th February 2013
I don't see oauth1 tokens as a short cut because eran said the token in
oauth1 (which is inside the oauth1 spec) had many implementation
problems by client developers. Why go there and re-invent what jwt could
do easily?
Do you need hok? Do you need replay protection? Do you need message
signing? Are asymmetric keys needed? I get the impression the group is
less interested in the last two.
There is also key distribution to resource server. I think we have
client nailed but getting keys to resource server needs some discussion
- especially if the path is through the token itself.
I suppose we can move faster if we assume rs obtains keys in an
unspecified manner like what happened in oauth1.
Phil
Sent from my phone.
On 2013-02-15, at 22:02, William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>> wrote:
All the same concepts/info are available in the AS: client ID, client
auth, and can deliver both token and secret. What's magic once the
client has the token that's missing?
------------------------------------------------------------------------
*From:* Phil Hunt <phil.h...@oracle.com <mailto:phil.h...@oracle.com>>
*To:* William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>>
*Cc:* Justin Richer <jric...@mitre.org <mailto:jric...@mitre.org>>;
Tim Bray <twb...@google.com <mailto:twb...@google.com>>; IETF oauth WG
<oauth@ietf.org <mailto:oauth@ietf.org>>
*Sent:* Friday, February 15, 2013 1:52 PM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
Conference Call - 11th February 2013
Sorry. I have to disagree. The way 1.0 is written, it is not a
shortcut to turn it into a token for 2.
Phil
Sent from my phone.
On 2013-02-15, at 13:04, William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>> wrote:
>I've brought it up before, but I think it might be worthwhile, at
least as an exercise, to define a method to get OAuth1-style tokens
from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
them >with a protected resource.
YES!
------------------------------------------------------------------------
*From:* Justin Richer <jric...@mitre.org <mailto:jric...@mitre.org>>
*To:* Tim Bray <twb...@google.com <mailto:twb...@google.com>>
*Cc:* William Mills <wmills_92...@yahoo.com
<mailto:wmills_92...@yahoo.com>>; IETF oauth WG <oauth@ietf.org
<mailto:oauth@ietf.org>>
*Sent:* Friday, February 15, 2013 12:54 PM
*Subject:* Re: [OAUTH-WG] Minutes from the OAuth Design Team
Conference Call - 11th February 2013
So that you can fetch and manage all your tokens using the same code
paths as the OAuth2 services. The "get a token" part will be
identical to Oauth2 Bearer (except for some details of what comes
back from the token endpoint, of course), it's the "use a token" bit
that really changes and is up in the air. You get to use scopes, and
state, and refresh tokens, and all the other good stuff.
I've brought it up before, but I think it might be worthwhile, at
least as an exercise, to define a method to get OAuth1-style tokens
from an OAuth2 token endpoint. You'd defer to OAuth1 for how to use
them with a protected resource.
-- Justin
On 02/15/2013 11:49 AM, Tim Bray wrote:
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 <mailto: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
<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>>:
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>>
*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:* 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>>:
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>>
*To:* Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>>; Phil Hunt <phil.h...@oracle.com
<mailto:phil.h...@oracle.com>>
*Cc:* IETF oauth WG <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>] 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>
>
>
>
>
>
> 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>
>> 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 <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 <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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
