Some additional input
From: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Sent: Thursday, April 21, 2011 12:28 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
This got a little bit too nested so I kept only the comments where we are not
on the same
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Fri, 22 Apr 2011 14:51:33 -0700
AJN- So the client credentials originate from WRAP also, it’s not completely
new, it may be new the way that it got worded but the same functionality was in
WRAP. The section 5.2
]
Sent: Friday, April 22, 2011 3:25 PM
To: Anthony Nadalin; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Fri, 22 Apr 2011 14:51:33 -0700
AJN- So the client credentials originate from WRAP also, it's
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3
I disagree here, this is not new or even completely new use case as this was in
WRAP as we are using this feature now. I would agree that it's not very well
documented but that was attempted by Yaron in his
...@microsoft.com]
Sent: Friday, April 22, 2011 3:34 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3
I disagree here, this is not new or even completely new use case as this was in
WRAP as we are using this feature now. I would agree that it's not very well
?
From: Anthony Nadalin tony...@microsoft.com
To: Eran Hammer-Lahav e...@hueniverse.com; Dick Hardt dick.ha...@gmail.com
Cc: OAuth WG oauth@ietf.org
Sent: Friday, April 22, 2011 3:45 PM
Subject: Re: [OAUTH-WG] Revised Section 3
Not sure I have to show you anything. The WRAP specification does
There is no extension in WRAP to allow this, it’s allowed as part of WRAP.
From: William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Friday, April 22, 2011 4:10 PM
To: Anthony Nadalin; Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
That WRAP allowed
Yes! Exactly as it is already allowed in v2.
EHL
From: Anthony Nadalin [mailto:tony...@microsoft.com]
Sent: Friday, April 22, 2011 4:12 PM
To: William J. Mills; Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3
There is no extension in WRAP to allow this, it’s
[mailto:tony...@microsoft.com]
Sent: Friday, April 22, 2011 3:45 PM
To: Eran Hammer-Lahav; Dick Hardt
Cc: OAuth WG
Subject: RE: [OAUTH-WG] Revised Section 3
Not sure I have to show you anything. The WRAP specification does not preclude
the usage of 2 assertions as this was one of the must support use
On 2011-04-22, at 5:18 PM, Eran Hammer-Lahav wrote:
Are you kidding me? “Not the best spelled out feature”?
It is not spelled at all. Not using a single character! Maybe Dick was using
magic ink for this section.
No magic ink was used. :)
Tony: I looked over your last emails and while I
This got a little bit too nested so I kept only the comments where we are not
on the same page.
From: Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com
Date: Thu, 21 Apr 2011 11:34:32 -0700
To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, Dick
Hardt
:06 PM
To: Eran Hammer-Lahav; Anthony Nadalin
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Revised Section 3
Resolves *my* confusion. :)
Tony: apologies if you covered this in earlier posts, but if 4.5 does not solve
your use case, would you clarify what else is needed? Are you unhappy that it
is labeled
...@hueniverse.com
Cc: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org
Subject: RE: [OAUTH-WG] Revised Section 3
So here is what I currently understand, I’m sure that I have some of this wrong;
1. At the Prague meeting the general issue of Client Credentials removal
from document was brought up, Thomas
On Mon, Apr 18, 2011 at 6:46 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Procedural issue:
The companies interested in this work have already showed interest
in other companion specification so the argument of having to point
developers to multiple documents is completely without merit.
-Original Message-
From: Dave Nelson [mailto:dnel...@elbrys.com]
Sent: Tuesday, April 19, 2011 5:25 AM
The claim that removing is a breaking issue is patently wrong.
From what I've read in this thread, I can't support that notion. If
interoperable implementations can't be
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf
Of Eran Hammer-Lahav
Sent: Tuesday, April 19, 2011 10:11 AM
To: Dave Nelson
Cc: oauth
Subject: Re: [OAUTH-WG] Revised Section 3
-Original Message-
From: Dave Nelson
Hey Thomas,
-Original Message-
From: Thomas Hardjono [mailto:hardj...@mit.edu]
Sent: Tuesday, April 19, 2011 8:44 AM
If its ok with you, may I offer some friendly suggestion.
Section 3 does not take away anything from your work and
enormous contribution to the Oauth 2.0 main spec.
On 2011-04-19, at 10:51 AM, David Recordon wrote:
I think requests like this and the following discussions have scared
away many of the original voices behind OAuth 2.0. As Eran said, the
goal was never to create a new framework but standardize interoperable
best practices that the industry
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, April 19, 2011 11:37 AM
The feature described was in OAuth-WRAP which was a basis for OAuth 2.0.
Can you please point me to where this feature was in WRAP? I can't find it.
EHL
On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, April 19, 2011 11:37 AM
The feature described was in OAuth-WRAP which was a basis for OAuth 2.0.
Can you please point me to where this
://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03
-Original Message-
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, April 19, 2011 11:59 AM
To: Eran Hammer-Lahav
Cc: David Recordon; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
On 2011-04-19, at 11:41 AM, Eran Hammer
[mailto:dick.ha...@gmail.com]
Sent: Tuesday, April 19, 2011 11:59 AM
To: Eran Hammer-Lahav
Cc: David Recordon; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote:
-Original Message-
From: Dick Hardt [mailto:dick.ha
...@hueniverse.com
Cc: record...@gmail.commailto:record...@gmail.com
record...@gmail.commailto:record...@gmail.com, oauth
oauth@ietf.orgmailto:oauth@ietf.org
Subject: Re: [OAUTH-WG] Revised Section 3
Thanks for clarifying. Given how you have broken out Section 3 from the rest of
the flow, I
, oauth oauth@ietf.org
Subject: Re: [OAUTH-WG] Revised Section 3
Thanks for clarifying. Given how you have broken out Section 3 from the rest
of the flow, I missed 4.5.
It is not clear in 4.5 that an access token is returned since in the
previous sections, there is a separate request
. Removing is a breaking issue.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Manger, James H
Sent: Thursday, April 14, 2011 8:47 PM
To: oauth
Subject: Re: [OAUTH-WG] Revised Section 3
I'm certainly in favour of excluding client auth from OAuth
-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Monday, April 18, 2011 2:53 PM
To: Manger, James H; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
3.3 Client Assertion Credentials. OAuth2 currently supports the concept of
a client app swapping an assertion
...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Monday, April 18, 2011 2:53 PM
To: Manger, James H; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
3.3 Client Assertion Credentials. OAuth2 currently supports the
concept of
a client app swapping an assertion
authentication
methods.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Monday, April 18, 2011 2:53 PM
To: Manger, James H; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
3.3 Client Assertion Credentials
, April 18, 2011 2:53 PM
To: Manger, James H; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
3.3 Client Assertion Credentials. OAuth2 currently supports the
concept of
a client app swapping an assertion for an access token. Do people
want the additional functionality of using
, James H; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
3.3 Client Assertion Credentials. OAuth2 currently supports the
concept of
a client app swapping an assertion for an access token. Do people
want the additional functionality of using assertions for generic
client
To make discussion easier, here is the proposed text:
[NOTE: Text for the following Section 3 is based on OAUTH draft-11]
3. Client Credentials
When interacting with the authorization server, the client identifies
itself using a set of client credentials which include a client
Thanks Thomas!
My notes below are not aimed specifically at Thomas but at those seeking to
have this section included. I'm going to skip any editorial feedback as I will
make those changes if and when incorporating this text into the v2
specification. I will say that the new section 3.2
On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote:
snip/
In practice, this invents a new HTTP authentication scheme.
Eran, during the WG meeting in Prague you said the same thing, and I
tend to agree. Yes, client authentication is a good thing, but given
that OAuth happens over HTTP I don't see why
Cc: Thomas Hardjono; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
On 4/14/11 3:56 PM, Eran Hammer-Lahav wrote:
snip/
In practice, this invents a new HTTP authentication scheme.
Eran, during the WG meeting in Prague you said the same thing, and I
tend to agree. Yes, client
+1
There is the issue of how a client app 'bootstraps' its own credential. It
could be that it authenticates by some other RFC (like 2617 Basic Auth), or
some other method. E.g. would be nice to have a way for client apps to obtain
either the equivalent of client_assertion, or even a MAC
]
Sent: Thursday, April 14, 2011 3:41 PM
To: Peter Saint-Andre
Cc: Eran Hammer-Lahav; oauth
Subject: Re: [OAUTH-WG] Revised Section 3
+1
There is the issue of how a client app 'bootstraps' its own credential. It
could
be that it authenticates by some other RFC (like 2617 Basic Auth
I'm certainly in favour of excluding client auth from OAuth. Dropping section 3
and just having a paragraph like the following would be preferable (with no
capitalized keywords):
In many cases an authorization server will require client
authentication for requests to a token endpoint.
, James H james.h.man...@team.telstra.com
To: oauth oauth@ietf.org
Sent: Thursday, April 14, 2011 8:47 PM
Subject: Re: [OAUTH-WG] Revised Section 3
I'm certainly in favour of excluding client auth from OAuth. Dropping section 3
and just having a paragraph like the following would be preferable
38 matches
Mail list logo
