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
Microsoft recently offered to sponsor me to work on OAuth. For the past few
months I have participated in the WG on my own time, but I am now able to
devote a significant amount of time to this WG.
I'd be happy to work on merging client signature support with WRAP. My
preference would be to sta
David
Although you stated you were taking WRAP and adding signatures, I found many
other differences between the specs. I'm baffled at why you essentially started
from scratch on this document rather than taking WRAP and adding the device
profile and signatures.
Per your previous email:
I don't think that Microsoft ever indicated that we need the SAML flows.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David
Recordon
Sent: Tuesday, March 23, 2010 10:48 AM
To: Torsten Lodderstedt; Chuck Mortimore; Mark Mcgloin
Cc: OAuth WG
S
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
Allen,
Right, the PR needs to have the client's access token so that it knows
which access tokens to accept. The AS issues the access token, so in
order for the PR to know the access token, the AS need to send a
secure message to the PR saying that "this access token is OK". This
commun
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
The other related use case here is the Google Apps marketplace model for
sitewide app auth:
http://code.google.com/apis/accounts/docs/OAuth.html#GoogleAppsOAuth
http://www.google.com/support/a/bin/answer.py?hl=en&answer=162105
On Mon, Mar 22, 2010 at 3:03 PM, Ethan Jewett wrote:
> On Fri, Ma
Hi Richard,
>From a security perspective, it might be undesirable to distribute the
client secret to all potential protected resources that a client might want
to access.
In many ways, distributing the client secret to all PRs is undesirable in
the same way that it's undesirable to distribute the
On Mon, Mar 22, 2010 at 3:03 PM, Ethan Jewett wrote:
> In any case, this is probably neither here nor there. I agree with
> your assessment of the two main interesting Open Social use cases.
> Especially the idea that it is an example of a type of trusted
> containers that can protect secrets from
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
Ah, ok. I disagree with this as blanket recommendation though it can make
sense in some cases.
Agreed that OAuth is more of a plug-in for HTTP than a separate protocol
layered on top.
On Tue, Mar 23, 2010 at 10:09 AM, Richard Barnes wrote:
> Well, the relevant part says "200 or 500"; the basic
Well, the relevant part says "200 or 500"; the basic message is that
if your HTTP-using application has an error, but the HTTP was OK, then
you shouldn't have an HTTP-layer error. So for instance, in the
GEOPRIV HELD protocol [1], every request returns 200 unless the HTTP
is screwed up, an
That's an interesting and informative RFC, but it recommends using the 500
response code for all errors (unless I'm misreading). Errors due to
incorrect input should be 4xx.
On Mon, Mar 22, 2010 at 10:02 PM, Richard Barnes wrote:
> In case it's helpful, BCP 56 / RFC 3205 provides recommendation
+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
35 matches
Mail list logo
