I might be interested too; agree that it's not core to this group.
Eve
On 23 Mar 2010, at 5:15 PM, Chuck Mortimore wrote:
> Outside the scope of what this WG should be tackling in the core spec IMO,
> but I’d be interested in working on a profile. There is a lot of this
> use-case be
On 24 Mar 2010, at 9:54 AM, Hans Granqvist wrote:
> On Tue, Mar 23, 2010 at 9:44 PM, Dick Hardt wrote:
>> ...
>> By keeping all profiles in one document, someone easily understands the
>> different applications of the technology, and when a different use case
>> comes up, they know it is availab
On Tue, Mar 23, 2010 at 9:44 PM, Dick Hardt wrote:
> ...
> By keeping all profiles in one document, someone easily understands the
> different applications of the technology, and when a different use case comes
> up, they know it is available rather than having to look at a different
> document
: [OAUTH-WG] First draft of OAuth 2.0
Agreed - I think that stems from my original note...sorry if it accidentally
put words in your mouth. I do believe that the original flow was authored by
Dick when he was at Microsoft, and it's my understanding that you've actually
similar pushed cod
behind this.
-cmort
From: Anthony Nadalin [tony...@microsoft.com]
Sent: Tuesday, March 23, 2010 9:53 PM
To: David Recordon; Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
Subject: RE: [OAUTH-WG] First draft of OAuth 2.0
I don't think that Microsoft ever indicated th
Hi Brian,
thanks for the clarification. Should the WG document this kind of
security design decisions somewhere?
regards,
Torsten.
On Tue, Mar 23, 2010 at 12:01 PM, David Recordon wrote:
§3
- Why is the parameter oauth_client_secret required for refreshing access
tokens? Use cases 2.2 a
On 2010-03-23, at 9:52 PM, Dick Hardt wrote:
>> My goal by removing some of the non-obvious things was to encourage
>> the discussion which has now started! Many of the design decisions
>> that went into WRAP haven't entirely been shared in public
Would you care to share the design decisions beh
That was one of the reasons why the refresh was repeated. Unfortunately I
dropped the secret mistakenly when I ported over to RFC format. See my comments
on draft-recordon-oauth2 for details.
On 2010-03-23, at 6:51 PM, David Recordon wrote:
> What about clients which don't have access to the cl
th WG
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0
Hey Chuck,
Thanks for rewriting the SAML flow into the style of my draft! I really
appreciate it.
I originally dropped the SAML flow because I hadn't seen support for it on the
mailing list(s) the past two months. I think that our defa
On 2010-03-23, at 12:16 PM, David Recordon wrote:
> On Tue, Mar 23, 2010 at 11:58 AM, Dick Hardt wrote:
>> David: perhaps if you asked the list about features before dropping
>> them we would not all have to argue with you about why to put them
>> back in.
>
> My goal by removing some of the no
On 2010-03-23, at 12:10 PM, David Recordon wrote:
> I'd like to pull the username/password and SAML flows into their own
> documents. I don't think that we want to propagate the usage of the
> password anti-pattern and while I'm hearing clearly that the SAML flow
> is needed, I don't think it wil
On 2010-03-23, at 12:05 PM, Chuck Mortimore wrote:
> No worries – I figured it would be easier to push for it’s inclusion if the
> work were minimal.
>
> We will definitely need to implement this style of profile, as will many
> others, so it’s essential it ends in some spec. Personally
And I realize that this issue was created because WRAP describes a
different refresh token flow for each profile whereas this draft
combines them all together. I think it's important to realize that
implementors will want to write one refresh_token(identifier,
refresh_token, secret?) function and e
What about clients which don't have access to the client secret? For
example, rich desktop applications and devices.
Seems like if the client secret is optional then a server can enforce
in policy what type of clients must pass it in.
--David
On Tue, Mar 23, 2010 at 5:56 PM, Brian Eaton wrote:
On Tue, Mar 23, 2010 at 12:01 PM, David Recordon wrote:
>> §3
>> - Why is the parameter oauth_client_secret required for refreshing access
>> tokens? Use cases 2.2 and 2.3 do not require the client to use (possess) a
>> secret. Does this imply such client are not entitled to refresh tokens? I
>> w
Outside the scope of what this WG should be tackling in the core spec IMO, but
I'd be interested in working on a profile. There is a lot of this use-case
being done in an ad-hoc manner on my platform.
-cmort
On 3/23/10 11:17 AM, "Paul Madsen" wrote:
Separate from the Client trading a SAML
Missed it, included now!
http://github.com/daveman692/OAuth-2.0/commit/099c51025d33e9a9350468c3e57482785d9826e8
On Tue, Mar 23, 2010 at 12:09 PM, Chuck Mortimore
wrote:
> By the way, did you see my little note at the end? It was kind of buried.
>
>
> I think the oauth_mode param is missing from
On Tue, Mar 23, 2010 at 11:58 AM, Dick Hardt wrote:
> David: perhaps if you asked the list about features before dropping
> them we would not all have to argue with you about why to put them
> back in.
My goal by removing some of the non-obvious things was to encourage
the discussion which has no
On Tue, Mar 23, 2010 at 12:05 PM, Chuck Mortimore
wrote:
> No worries - I figured it would be easier to push for it's inclusion if the
> work were minimal.
Yeah, definitely!
> We will definitely need to implement this style of profile, as will many
> others, so it's essential it ends in some sp
No worries - I figured it would be easier to push for it's inclusion if the
work were minimal.
We will definitely need to implement this style of profile, as will many
others, so it's essential it ends in some spec. Personally I'd rather see a
relatively thin spec that includes the critical p
Inline and thanks for the feedback!
On Tue, Mar 23, 2010 at 11:14 AM, Torsten Lodderstedt
wrote:
> Hi David,
>
> I have a couple of questions/comments:
>
> §2 - The flows use shared secrets for client authentication only. What about
> adding support for public-key-based signatures for that purpos
David: perhaps if you asked the list about features before dropping
them we would not all have to argue with you about why to put them
back in. Frankly I was surprised that you did not circulate the draft
to me as editor of WRAP.
WG Chairs: Is this draft now the draft that the WG is working on and
Hi David,
would it simplify the specification if there would be a generic workflow
in section 2 which defines the parameters that are common to all flows?
regards,
Torsten.
Hey Chuck,
Thanks for rewriting the SAML flow into the style of my draft! I
really appreciate it.
I originally dropped
Separate from the Client trading a SAML assertion for an Access Token as
in this flow, we are interested in defining how a Client might use SAML
SSO messages to get an Access Token (comparable to OpenID/OAuth hybrid).
Anybody else interested?
paul
On 3/23/2010 1:47 PM, David Recordon wrote:
Hi David,
I have a couple of questions/comments:
§2 - The flows use shared secrets for client authentication only. What
about adding support for public-key-based signatures for that purpose as
an alternative? That's one of the use cases on
http://trac.tools.ietf.org/wg/oauth/trac/wiki/Signatu
Hey Chuck,
Thanks for rewriting the SAML flow into the style of my draft! I
really appreciate it.
I originally dropped the SAML flow because I hadn't seen support for
it on the mailing list(s) the past two months. I think that our
default should be making the spec as short and simple as possible
Thanks John; incorporated your wording.
http://github.com/daveman692/OAuth-2.0/commit/4c93341a85c70c0954945be636a8dce359fccb0f
On Tue, Mar 23, 2010 at 10:25 AM, John Panzer wrote:
> On Sun, Mar 21, 2010 at 6:12 PM, Eve Maler wrote:
>>
>> On 21 Mar 2010, at 1:43 PM, David Recordon wrote:
>>
>> >
On Sun, Mar 21, 2010 at 6:12 PM, Eve Maler wrote:
> On 21 Mar 2010, at 1:43 PM, David Recordon wrote:
>
> > The goal of the, "the authorization server advertises (such as via
> documentation) the URIs of the following three endpoints" wording was to
> allow for a discovery process that is defined
+1 for assertion support
what about enhancing the flow #2.4 to accept any kind of user
credentials (username/password, SAML assertions, other authz servers
tokens)
regards,
Torsten.
Am 23.03.2010 um 12:42 schrieb Mark Mcgloin :
+1 for assertion profile. Was there any reason why it was dr
+1 for assertion profile. Was there any reason why it was dropped?
On 3/23/10, Chuck Mortimore wrote:
>Just getting a chance to review this – I apologize for not getting this
before the meeting started.
>We’d like to see some form of an Assertion Profile, similar to section 5.2
from draft-hardt-o
Just getting a chance to review this – I apologize for not getting this before
the meeting started.
We’d like to see some form of an Assertion Profile, similar to section 5.2 from
draft-hardt-oauth-01. We have strong customer use-cases for an assertion
based flow, specifically SAML bearer tok
oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Panzer
Sent: Monday, 22 March 2010 6:54 AM
To: Eve Maler
Cc: OAuth WG
Subject: Re: [OAUTH-WG] First draft of OAuth 2.0
+1 to ensuring that dynamic introduction is possible. I see a lot of
discussions that end up saying that th
On Sun, Mar 21, 2010 at 8:26 PM, Eve Maler wrote:
> Selected thoughts in response:
>
> On 21 Mar 2010, at 3:51 PM, David Recordon wrote:
>
>> Thanks! Comments inline and updated the repo
>> (http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).
>>
>> On Sun, Mar
Selected thoughts in response:
On 21 Mar 2010, at 3:51 PM, David Recordon wrote:
> Thanks! Comments inline and updated the repo
> (http://github.com/daveman692/OAuth-2.0/commit/3193098ff45168dd0a65456334428b20215f848a).
>
> On Sun, Mar 21, 2010 at 12:03 PM, Eve Maler wrote:
>> David, great stu
On 21 Mar 2010, at 1:43 PM, David Recordon wrote:
> The goal of the, "the authorization server advertises (such as via
> documentation) the URIs of the following three endpoints" wording was to
> allow for a discovery process that is defined separately from this spec. Is
> that unclear? Have
The goal of the, "the authorization server advertises (such as via
documentation) the URIs of the following three endpoints" wording was to allow
for a discovery process that is defined separately from this spec. Is that
unclear? Have other words to propose?
Eve, thanks for the detailed feedb
+1 to ensuring that dynamic introduction is possible. I see a lot of
discussions that end up saying that this or that can be spec'd in the
server docs and the client hard coded to the docs; this is fine for
some features but not for very general ones that everybody needs to
use.
On Sunday, March
David, great stuff -- thanks for putting this together! Here are a few
comments and questions from a quick read on the plane down to Anaheim, in spec
order (the weight/priority therefore varies widely).
Abstract
- "delegate": The use of this word seems like it's different from how it's been
u
38 matches
Mail list logo
