Right, and one of the main ways you'd use the chaining grant is by parsing the
incoming token as an assertion of some type. They're all blocks that are made
to fit together.
-- Justin
On Jul 19, 2013, at 3:32 PM, Brian Campbell
mailto:bcampb...@pingidentity.com>> wrote:
FWIW, the 3 assertion
FWIW, the 3 assertion documents are more targeted at cross domain type use
cases. For example, assuming a trust (and liklely legal) relationship is in
place, some corporate system acting as the client can trade a SAML token in
at the AS of a SaaS provider for an OAuth access token, which can then b
The additional fields would be passed back from the token introspection
endpoint. That is what we do in Ping Federate. We still need to come up with
a token introspection standard so implementations are currently doing there own
things.
John B.
On 2013-07-19, at 1:22 PM, Todd W Lainhart wro
Absolutely -- you can have a random blob token or anything else. We
picked the field names to be consistent with JWT where it made sense.
-- Justin
On 07/19/2013 11:36 AM, Todd W Lainhart wrote:
Thanks. Is it assumed/valid that the "aud" field can be used in
non-JWT environs?
*
Todd Lain
Hi Nadalin,
that means, that I would use an existing OAuth-2-Token as the assertion for
requesting another OAuth-2-Token, right?
Section 5.2. "General Assertion Format and Processing Rules" of this draft
says, that the assertion has to contain an Issuer as well as an audience.
The OAuth-2-
> Typically someone would have a shadow account that would deal with
lining the identities from multiple IdP into the local account and assert
the local identifier to the RS.
Yes, that where I was going.
> I would personally treat passing the additional external identifiers as
extra claims t
Hi Prateek,
thouse drafts go in the right direction, but as you mention, they need
additional profiling.
The drafts, that Justin mentioned in the mail before (see [1] and [2]), seem
to do exactly that.
With "a resource server could delegate a subset of the delegated rights to
another r
Hi Manfred,
This is an area of interest to us and we have done some profiling in our
implementation.
Generally speaking, we work with the assertion profiles as a starting
point. They allow for WS-Trust
like token exchanges and (implicitly) support ActAs or OnBehalfOf. But
they do need additi
You can accomplish the ActAs semantics with Assertions profile, while a bit
clumsy the basics are in place, the only issue is that you don't have any way
to indicate the formal semantics
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Prateek Mishra
Sent: Friday, July
I think most people look this similarly to SSO account mapping. Typically
someone would have a shadow account that would deal with lining the identities
from multiple IdP into the local account and assert the local identifier to the
RS.I would personally treat passing the additional extern
Yes, the drafts are expired, but that's largely because there hasn't
been enough traction in the IETF to push them forward yet. It doesn't
mean that the mechanisms in them don't work though, and if we can get
more support behind them (which includes implementations) we can
eventually put them i
Thanks. Is it assumed/valid that the "aud" field can be used in non-JWT
environs?
Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
lainh...@us.ibm.com
From: Justin Richer
To: Todd W Lainhart/Lexington/IBM@IBM
Thanks to Prateek and John for the replies.
I agree that the required mapping should be done by the AS, and that the
user portion of the identity may not be unique (as John said in a later
reply). I'm still trying to figure out to if the RS should pass a scope
that might be a clue to the AS as
The "aud" field came from JWT:
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-10#section-4.1.3
The links in section 2.2 are correct -- they link to the reference in
section 6, which has the URL for the actual RFC of OAuth 2.0 there. I
agree that it's a weird way to handle hyperlink
While I won't profess to be proficient at SAML, I can say that there
have been a couple tries at defining a "chained delegation" grant extension:
http://tools.ietf.org/html/draft-richer-oauth-chain-00
http://tools.ietf.org/html/draft-hunt-oauth-chain-01
We've deployed the first one with a coup
http://tools.ietf.org/html/draft-richer-oauth-introspection-04#page-3
lists the "aud" field as an optional field in the introspection response.
Could someone give examples of its intended use? Did this come from OIDC?
Also Justin - it appears that the section links to the OAuth 2.0 spec in
Sect
I agree that 429 seems to be the more appropriate status code for this
case - I wasn't aware of these extensions.
Re how to reconcile application errors/status that are outside the OAuth
domain, I've also struggled with that a bit. My current position is to
try and fit the error response withi
Hi,
are there plans for supporting delegation-styles like ActAs or OnBehalfOf in
SAML?
If this was possible, a resource server could delegate a subset of the
delegated rights to another resource server. This could be a very important
thing, when one wants to use OAuth 2 within an enterprise
18 matches
Mail list logo
