The Assertion Flow is for the AS to act as an STS where one token is
exchanged for another. This allows the PR to not have to worry about
different kinds of tokens and to only deal with tokens issued by an AS.
Lisa: a real world example of your use case would make it easier for how you
got to 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). The
Begin forwarded message:
From: Jim Brusstar mailto:jim...@facebook.com>>
Subject: [auth-protocols] Typo in OAuth2 Draft
In §3.7.2 Client Requests Access Token, the ‘code’ parameter is not listed as
REQUIRED, when it in fact should be (otherwise it should be marked OPTIONAL,
but that doesn’t seem
Lisa,
I'm also looking at the assertion flow right now
and wondering if I could use it to "swap" a
Kerberos service-ticket for an OAuth Access-Token.
In particular, I would like to:
(1) Wrap the KRB AP_REQ message within a SAML-assertion
(eg. using the existing WSS Token Profile standard),
(2
I've been trying to understand the use case for the assertion flow (
http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.10) .
Conversely, I have a use case for bootstrapping, and I'm trying to
understand if the assertion flow is the right flow for that use case.
The bootstrapping use case