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
in its own spec.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Anthony Nadalin
Sent: Tuesday, August 03, 2010 3:29 PM
To: Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0
draft
verification is out 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
a separate profile 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
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
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] On Behalf Of Prateek
Mishra [prateek.mis...@oracle.com]
Sent: Wednesday, August 04, 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
, 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
-
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Tuesday, August 03, 2010 1:12 PM
To: Anthony Nadalin
Cc: oauth
Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0
draft
Seems like a much more complicated scenario. Allowing more than one
assertion, off
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
the claim, we still
expect that the signature verification is out 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
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking the state and the potential that it's unnecessarily
restrictive. I
+1 on MAY; (+0.3 on SHOULD).
Igor
Torsten Lodderstedt wrote:
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking
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
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
Yes - this is intended to be a simplified parallel to web sso profile. We also
intend to ship a straight adaptation of websso, as do others I believe
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
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
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking the state and the potential that it's unnecessarily
restrictive. I don't personally see either as being a major issue but
would like
Am 19.07.2010 06:34, schrieb Brian 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:
Hi Brian,
thank you for taking the effort to write this I-D.
I have the following remarks:
Why do you prescribe to include the token endpoint URL into the
SubjectConfirmationData and similar data also in the
AudienceRestriction? I would expect such data in the AudienceRestriction
only.
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
I'm gong to join the growing list of people attaching a potential I-D
to an email due to he cut off time for the I-D submissions. Attached
is a draft that aims to tightly define the particular format of a SAML
2.0 bearer assertion in requesting an access token using the assertion
grant_type.
22 matches
Mail list logo
