I think STS was used in the generic sense, ie token in, token out
Although a SOAP-binding for the flow would be wonderfully perverse
paul
On 03/06/2010 10:54 AM, Thomas Hardjono wrote:
Dick, Brian,
Thanks for the clarification.
- Is the Assertion Flow designed only for the STS,
or can it be used with other "identity providers" (non-WSS).
- Also, is it the expectation that a "profile" of OAuth2.0
be created to address certain use-cases.
PS. Compared to the details of RFC4120 and even
to the old ISAKMP in the IETF, the current
OAuth2.0 draft-05 spec appear to be a high-level framework
that needs to be instantiated/profiled.
/thomas/
__________________________________________
-From: Dick Hardt [mailto:dick.ha...@gmail.com]
-Sent: Thursday, June 03, 2010 1:51 AM
To: Brian Campbell
Cc: Thomas Hardjono; oauth
Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping
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 requirements you stated (ie. I am confused :)
-- Dick
On Wed, Jun 2, 2010 at 8:09 PM, Brian Campbell<bcampb...@pingidentity.com>
wrote:
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 use of SAML 2 tokens is suggested in
draft-ietf-oauth-v2-05 but one could imagine SAML 1.1, Kerberos (along
the lines of what Thomas outlines though I don't know enough about
Kerb to really comment), X.509, or whatever. Perhaps part of Lisa's
use case could be addressed by profiling a flow that defines an Access
Token being exchanged for a different Access Token? And the initial
bootstrapping could maybe be accomplished via the Client Credentials
Flow?
On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono<hardj...@mit.edu> wrote:
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) Deliver it using the OAuth assertion flow to a special
Kerberized-service (or IdP or OP), who then verifies
the Authenticator and Service-Ticket within
the AP_REQ message.
(3) Obtain in return an OAuth Access-Token with
the same lifetimes/expiration as defined in the original
service-ticket (in the AP_REQ request).
(4) Present the Access-Token to an OAuth Resource Server.
(ps. Alternatively, I could use the Kerberos delegation feature
but that may be more complicated).
I think Section 3.10 needs more fleshing-out.
/thomas/
__________________________________________
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Lisa Dusseault
Sent: Wednesday, June 02, 2010 1:33 PM
To: oauth
Subject: [OAUTH-WG] Assertion flow and token bootstrapping
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 I have in mind is to allow a client to interact
with a related set of services by bootstrapping from client secret to an
access token, and then from that access token to other access tokens. For
example, in a "login" interaction the client would get a generic access
token. Later, to use various services -- access to personal data, access to
friends' data, attempts to do uploads -- the client would ask the security
token server for access to new resources by URI, and if access was granted,
receive new access tokens which could be used on those services. The client
secret is not reused very often, and policy is centralized.
This seems similar to other use cases being discussed and so it's possible
my main point of confusion is trying to tie this to the assertion flow
instead of something else.
The assertion flow has the right number of parties involved, and it could
certainly be hacked/extended to do bootstrapping: instead of the client
secret, the general session access token could be used, and the "assertion"
field can contain anything including the URI of the service that the client
now wants. However I wondered if something less generic could make this
more interoperable.
Any thoughts?
Thanks,
Lisa
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
