On Tue, May 31, 2011 at 12:00 PM, Doug Tangren d.tang...@gmail.com wrote:
I think there is still a usability issue with the implicit flow in general
where there is no way in the spec to obtain an access token without
re-asking the user for authorization a second time even if the user has
.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Wednesday, May 25, 2011 3:03 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] TODO: Mike J./Chuck M. (or me) to draft 4.5.1
subsection on assertions
So
) will be
used for authentication and also to grant authorization as this is what was
in scope with WRAP, so not addressing the assertion authentication is an
issue for us and I assume others also.
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Wednesday
Currently (draft -16) client_id is listed as a required parameter for
access token request to the token endpoint for all grant types except
for extensions. In section 3 there is some disposition of the use of
client_id as a means of identification and then, in 3.2, a requirement
that client
I noticed yesterday, in -16, that the first time that client_id is
mentioned is in a parenthetical in the second paragraph of section 3.1
which is a little awkward. The client_id parameter then shows up
inside two examples before being listed as a required parameter in
section 4.1.1, 4.1.3, 4.2.1
I wanted to respond to this comment (sorry it's a few months later) to
say that those security considerations are important but I believe
they are already covered by the normative language in the SAML-bearer
spec as well as the references to the SAML Core and the SAML Security
and Privacy
%2F2.0%2F
bearerassertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDUtM
[...omitted for brevity...]V0aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
Thanks,
Brian
On Mon, May 23, 2011 at 8:48 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
These changes touch on, but don't necessarily address, some
Looks like they are starting now.
On Mon, May 23, 2011 at 9:35 AM, Doug Tangren d.tang...@gmail.com wrote:
For those joining remotely does the meeting actually start @ 9 or 10. I
looks like there's an hour of breakfast at 9 (pst). I'm in nyc so that's my
lunch time.
-Doug Tangren
Yeah, I had just sort of being going off the assumption that
client_id is required client_secret is not but, looking at -15
again, I agree that it's not entirely obvious. There's the text at
the end of section 3 that say allows for unauthenticated clients.
Then in 3.1 both client_id
check they match - that's the basic auth binding).
I'll clarify it.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, May 16, 2011 3:45 PM
To: Vlad Skvortsov
Cc: Eran Hammer-Lahav; oauth@ietf.org
Subject: Re: [OAUTH-WG] unauthenticated
There's tiny little typo in
http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-4.1.3 where
parameter should be parameters
-- Forwarded message --
From: Peter Motykowski pmotykow...@pingidentity.com
Date: Thu, Apr 14, 2011 at 9:56 AM
Subject: OAuth spec typo
To: Brian
Sadly, I am not in Prague. Given the similarities between the JWT and
SAML grant drafts, please let me know if anything substantial comes
out of the JWT discussions. Thanks!
On Thu, Mar 31, 2011 at 3:05 PM, Mike Jones michael.jo...@microsoft.com wrote:
To this, I'd like to add discussion of
Yeah, maybe it could be clarified a bit. Thanks. It made sense when I
first read the text. However, when I went to implement it, I started
reading into previously approved (maybe too much) and I think maybe
that wording is potentially ambiguous.
On Tue, Mar 29, 2011 at 5:16 PM, Eran Hammer-Lahav
I'm a bit confused by the text at the end of the definition of the
scope parameter in section 6 on Refreshing an Access Token[1]. It
says,
... The requested scope MUST be equal or lesser
than the scope originally granted by the resource owner, and if
omitted is treated
4.1.1: Scope string matching rules are ambiguous
In the scope definition, add The space-delimited strings are case
insensitive.
Good call.
I'd like to better understand why? Other than a means to delimit and
allow for multiple values, the spec is otherwise leaving the
interpretation of
. Also, in the case
of URI values, they are usually case insensitive.
EHL
-Original Message-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Friday, March 25, 2011 8:00 AM
To: Eran Hammer-Lahav
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] Feedback on draft
Thank for the review and comment, Peter, some replies and new
questions are inline below.
On Wed, Mar 23, 2011 at 11:05 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
I've completed a review of this spec, the bearer token spec, and the
base spec. This is the first WGLC message I found in my
in a single paragraph. Such a proposal would fit right in with
last call feedback to -13.
EHL
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Wednesday, February 16, 2011 1:39 PM
To: Eran Hammer-Lahav
Cc: Brian Campbell; OAuth WG
Subject: Re: [OAUTH-WG
Exactly Marius, and in most cases the app will want to procure a
refresh token as a result of the dance so it won't have to put the
user though the authorization process again and again. Unless I'm
mistaken, the implicit grant provides no means of obtaining a refresh
token
#2
On Wed, Feb 9, 2011 at 7:51 AM, Skylar Woodward sky...@kiva.org wrote:
#2
On Feb 9, 2011, at 12:04 AM, Mike Jones wrote:
Given that people are clearly voting to change the bearer token scheme name,
but that there is also significant discussion asking for “OAuth2” to be part
of the
The changes in this draft are only editorial cleanup items. Review
and feedback is always welcome, however.
-- Forwarded message --
From: internet-dra...@ietf.org
Date: Fri, Feb 4, 2011 at 2:30 PM
Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-03.txt
To:
Also #1
On Thu, Feb 3, 2011 at 1:47 PM, Justin Hart jh...@photobucket.com wrote:
#1, which is nice to support the OAuth2 scheme as previously discussed
(Hunt, etc) as a legacy type (can be specified in a migration spec).
-- Justin Hart
-- jh...@photobucket.com
On Feb 3, 2011, at
I'm happy to make that change. But is it really necessary? The
assertion parameter in draft-ietf-oauth-saml2-bearer is defined in the
context of using the
http://oauth.net/grant_type/assertion/saml/2.0/bearer; grant type.
Couldn't it be argued that other URI grant types could make use of it
FYI on a new SAML/OAuth draft. Mostly minor changes (copied from
appendix below) to align better with draft-ietf-oauth-v2-12
As always, feedback is welcome. Thx, Brian
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-01 (hopefully up soon)
or the less pretty version
All in all, I like the new structure of the document. Below are a few
editorial nits and questions.
http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-1.4 The
diagram has Access Grant but it seems like the rest of the draft is
now using authorization grant as per section 1.3?
I'd argue that, for reliable interoperability, both of those cases would
require an extension or at least some level of agreement about the format
and validation rules of the assertion.
On Thu, Jan 20, 2011 at 2:08 PM, Marius Scurtescu mscurte...@google.comwrote:
On Tue, Jan 18, 2011 at 10:12
:
On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
I'd argue that, for reliable interoperability, both of those cases would
require an extension or at least some level of agreement about the format
and validation rules of the assertion.
I do agree
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Campbell
Sent: Thursday, December 09, 2010 1:38 PM
To: oauth
Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01
security considerations
I know draft-ietf-oauth-v2
I guess I'm in the minority but I prefer option #1.
I do agree with others that naming with respect to authenticated vs.
unauthenticated clients is likely problematic.
On Wed, Jan 12, 2011 at 2:06 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
+1 for option 2 because it will
for this and this was
already proposed a long time ago with no objections.
EHL
-Original Message- From: Brian Campbell
[mailto:bcampb...@pingidentity.com] Sent: Tuesday, December 14,
2010 10:18 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth
Subject: Re: [OAUTH-WG] Fwd: New Version
implement assertions just by reading the framework spec,
you still need the SAML work.
This will require moving the SAML into a WG item (not a must but best) which
I am supportive of and would like to see happen quickly (in a few days).
Thoughts?
EHL
-Original Message-
From: Brian
.
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Campbell
Sent: Thursday, December 09, 2010 1:38 PM
To: oauth
Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01
security considerations
I know
I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit,
however, a couple things jumped out at me in areas that hadn't
received much attention yet so I wanted to raise the questions on a
separate thread.
Near the end of section 3.2. Threat Mitigation, it says:
Furthermore, the
Yes Torsten, I believe the consensus we ended up out of that last
discussion was that the spec and associated security considerations
should be written in such a way as to allow for either approach.
On Fri, Oct 1, 2010 at 10:55 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Prateek,
as
+1 seems like a pragmatic compromise
On Tue, Sep 28, 2010 at 12:44 PM, Marius Scurtescu
mscurte...@google.com wrote:
On Tue, Sep 28, 2010 at 9:05 AM, George Fletcher gffle...@aol.com wrote:
+1 I think this is a great path forward
+1
Marius
___
Yeah, that is true. One of my reasons for bringing this up was in
consideration of proposing a similar simplification around client
authentication. But clearly client authn and grants can and will be
presented together in the same request. I was aware of the potential
for name conflicts but
On Tue, 2010-09-21 at 17:11 -0400, Brian Campbell wrote:
Following from that (Justin: url-defined grant type can also legally
add and remove parameters from the endpoint, right? / Eran: Yes)
does the assertion parameter still make sense to have in the core
spec? I had sort of assumed that it would
It really depends on the requirements or policy of the authorization
server. For the I-D I've been working on,
https://datatracker.ietf.org/doc/draft-campbell-oauth-saml/, there's
nothing that binds of the assertion to the client. So there's not a
requirement for that enforcement nor is there
revocation is not
possible in a constellation as described before.
Regards,
Stefanie
Am 10.09.2010 00:38, schrieb Brian Campbell:
Isn't that kind of situation exactly the reason that access token
revocation was made optional? Invalidation of access tokens on
revocation of a refresh token
Thanks Thomas,
With respect to
https://datatracker.ietf.org/doc/draft-campbell-oauth-saml/, I'm
planning on updating it to come inline with draft -11 when it's
published as well as a couple other updates related to subject conf
and subject that have been discussed on this list. As it stands, I'm
On Thu, Aug 12, 2010 at 2:04 PM, David Recordon record...@gmail.com wrote:
Given that, would you strongly object to these proposals being written
in a separate document than the core spec? The device flow is a good
example of where we're doing this. We really think that it will be
useful, are
I generally agree more with Chuck, David and Brain E than I don't.
But I do think that someone will find a pragmatic reason for 1
assertion eventually and I think the proposal earlier in this thread
to allow for multiple occurrences of the assertion parameter in the
core spec will make that
On Thu, Aug 12, 2010 at 11:19 AM, Chuck Mortimore
cmortim...@salesforce.com wrote:
I think it would be reasonable to loosen the language to reflect that the
subject is who access will be granted to. It may or may not be the
resource owner, I agree.
Any thoughts on what that would look like
I received some feedback on the SAML profile from a cross posting on
the OASIS SSTC (SAML) list. Links to the thread topic index are
below[1], if you are interested, but I'll try and summarize the two
primary issues here.
First, concern was expressed that restricting the assertion to only
allow
The question of allowing for multiple assertions in the SAML profile
came up recently. See
http://www.ietf.org/mail-archive/web/oauth/current/msg04068.html and
several subsequent messages in the thread.
I pushed back on the idea at first due to added complexity. There are
a number of things
On Wed, Aug 4, 2010 at 3:00 PM, Prateek Mishra
prateek.mis...@oracle.com wrote:
Thanks for the clarification (Paul, Chuck and Brian), re-reading the most
recent draft makes the use-case pretty clear, not sure how I came up with my
own personal use-case in this instance (not enough coffee
On Wed, Aug 4, 2010 at 9:08 AM, Prateek Mishra
prateek.mis...@oracle.com wrote:
Brian,
it would probably help to clarify that you are proposing this as a
additional or follow-on step to SSO implemented via the SAML web browser
profiles (right?).
Actually no.
The similarities to SSO are
, 2010 8:08 AM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
Brian,
it would probably help to clarify that you are proposing this as a
additional or follow-on step to SSO implemented via the SAML web browser
profiles (right
of scope.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Campbell
Sent: Monday, August 02, 2010 2:53 PM
To: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
I guess I'd need to understand the scenario
for that
or add it as an option here.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Brian Campbell
Sent: Thursday, July 15, 2010 1:50 PM
To: oauth
Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft
I'm gong
MAY it is. Thanks
On Jul 28, 2010 4:06 AM, Igor Faynberg igor.faynb...@alcatel-lucent.com
wrote:
+1 on MAY; (+0.3 on SHOULD).
Igor
Torsten Lodderstedt wrote:
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
...
___
OAuth mailing
A client_id parameter would still be presented in the end user
authorization request. The text Brian E. quoted is what mandates any
specifications/documents/agreements that define how to use client
assertions must also define the association between the client_id and
some field(s) in the
On Thu, Jul 22, 2010 at 3:39 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Sounds like you defining a profile of the OAuth assertion flow for using
SAML assertions complying to the SAML Web Browser SSO Profile. I think you
should state that somewhere. There will probably be other
On Tue, Jul 27, 2010 at 12:26 PM, Chuck Mortimore
cmortim...@salesforce.com wrote:
For both of these, We intend to enforce one time use; I suspect that type of
state maintenance will get argued against by those running the large
scale consumer systems...it's manageable for us given how our
implementing/supporting this.
Here's the link: http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt
Thanks,
Brian Campbell
-- Forwarded message --
From: IETF I-D Submission Tool idsubmiss...@ietf.org
Date: Tue, Jul 27, 2010 at 1:14 PM
Subject: New Version Notification for draft-campbell
Torsten,
Thanks for taking the time to review and comment. I've tried to
address your questions inline below (though in some cases only raising
more questions).
On Sun, Jul 18, 2010 at 9:48 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Why do you prescribe to include the token endpoint
:
On Fri, Jul 16, 2010 at 12:22 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
+1 for something different but not client password as sounds like it
would preclude other methods of client authentication
I think it would work like this:
grant_type=client_password:
maps to the client
I agree it's important but it belong in security considerations or
perhaps somewhere in the definition of the Authorization Code itself?
Either way here's some text that could be used as a starting point. I
borrowed heavily from concepts and language in SAML regarding
artifacts and IDs which
- it would only
provide one concrete definition to implement against.
I intend to submit this as an I-D when the submission process reopens.
Any feedback from this group would be appreciated as well as
thoughts about this eventually becoming a working group draft.
Thanks,
Brian Campbell
As written it probably does preclude that but I'm sure we could
massage it to be more flexible while still keeping the intent that the
code isn't something that can be easily guessed or is likely to
collide.
I must admit to never having considered the authz code as anything but
a random string as
to the URL length in
the 302 (I think it has to be a redirect).
On Thu, Jul 15, 2010 at 3:30 PM, Brian Eaton bea...@google.com wrote:
On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
I must admit to never having considered the authz code as anything but
a random
On Thu, Jul 15, 2010 at 5:36 PM, Brian Eaton bea...@google.com wrote:
There are certain practical limits, but I think there is still blood
on the specification from the last time normative language was
discussed.
That must have been been before my time - sorry for bringing it up
again. We can
Sounds like it's already in for -09 but I'd still like to voice my support
for some kind of optional parameter like error_description.
I'm working on a draft profiling a specific use of SAML in the assertion
grant_type flow (coming soon to this list I hope) and added in an
error_detail parameter
I noticed (don't ask how) two tiny little things in the POST body in
the example in section 4.1.3. Currently it has:
grant_type=assertionclient_id=s6BhdRkqt3client_secret=diejdsks
assertion_type=urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion
assertion=PHNhbWxwOl...[ommited for
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
At least for the assertion flow, that's definitely true. At the interim
meeting we had some discussion about perhaps pulling the assertion flow
out of the base spec and into a separate document. Perhaps that's the
I'm still a newbie here so someone please correct me if I'm wrong, but
I believe the Assertion Flow was intentionally left generic to serve
as an extension point for profiling more specific types of
assertions/tokens being exchanged for OAuth Access Tokens (or allowing
for proprietary usage).
credential, the validity of the refresh
token... - seems like somethings missing here?
Regards,
Brian Campbell
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
1101 - 1167 of 1167 matches
Mail list logo
