Subject: [OAUTH-WG] Assertion flow and token bootstrapping

From: Lisa Dusseault <[email-masked]>
Date: Wed, 2 Jun 2010 10:32:31 -0700

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

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 2 Jun 2010 14:56:56 -0400

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: [email-masked] [mailto:[email-masked]] 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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Jun 2010 21:09:35 -0600

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 <[email-masked]> wrote:
>
>
> Lisa,
>
>
>
> I’m also looking at the assertion flow right now
>
> and wondering if I could use it to  “swap” a
>
> 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) .
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 2 Jun 2010 22:51:18 -0700

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
<[email-masked]>wrote:

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Lisa Dusseault

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 03 Jun 2010 12:22:24 +0200

If I understand you correct, then you could utilize the assertion flow 
as follows:

Put the generic token into the assertion parameter, set the scopes 
parameter to the scope(s) of the service your client wants to interact 
with and use the client credentials as described. If the AS supports 
such a token swap, then it should respond with a new access token 
applicable for the target services. Pre-Requisite: The original token 
must have been authorized for the target service (scope). How do you 
want to achieve that? Which flow do you want to obtain the first access 
token?

Alternatively, your client could also obtain all tokens required to 
access the target services in the initial authorization flow. Please 
take a look on the thread about multiple access tokens from one 
authorization flow 
(http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html).

regards,
Torsten.

Am 02.06.2010 19:32, schrieb Lisa Dusseault:
> 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
>
>

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 3 Jun 2010 10:54:54 -0400

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:[email-masked]] 
-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 <[email-masked]> wrote:

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 09:20:44 -0600

> that needs to be instantiated/profiled.

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
best way to proceed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Madsen <[email-masked]>
Date: Thu, 03 Jun 2010 11:30:17 -0400

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:
> On Wed, Jun 2, 2010 at 8:09 PM, Brian Campbell<[email-masked]>  wrote:
> On Wed, Jun 2, 2010 at 12:56 PM, Thomas Hardjono<[email-masked]>  wrote:
>    
>>
>> Lisa,
>>
>>
>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 3 Jun 2010 08:32:36 -0700

> or can it be used with other "identity providers" (non-WSS).

It can be used with any tokens. I use the STS term to clarify the design pattern.

> be created to address certain use-cases.

Such as?

> that needs to be instantiated/profiled.

Agreed there are some aspects of OAuth that are left to other documentation. Standardizing what can easily be standardized has proven very useful to implementors.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Thu, 3 Jun 2010 08:34:26 -0700

> out of the base spec and into a separate document. Perhaps that's the

I think all of the flows have some aspect that requires the developer reading some context specific documentation to implement and that standardizing what we can is useful.  The assertions being passed around are based on specs that themselves need to be profiled often.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Jun 2010 15:38:13 -0600

> out of the base spec and into a separate document. Perhaps that's the

I'd like to see the assertion flow remain in the base spec.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 04 Jun 2010 23:42:30 +0200

+1

Am 04.06.2010 23:38, schrieb Brian Campbell:
> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre<[email-masked]>  wrote:
>

---

From: Patrick Harding <[email-masked]>
Date: Fri, 4 Jun 2010 19:41:32 -0400

+1

Sent from my iPhone

---

From: Luke Shepard <[email-masked]>
Date: Fri, 4 Jun 2010 18:40:24 -0700

Why?

---

From: Dick Hardt <[email-masked]>
Date: Fri, 4 Jun 2010 18:58:55 -0700

because we use it

---

From: Thomas Hardjono <[email-masked]>
Date: Sun, 6 Jun 2010 18:22:55 -0400

Apologies for another newbie question: is the design-intention underlying the Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP draft (draft-hardt-oauth-01)?

/thomas/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dick Hardt
> Sent: Friday, June 04, 2010 9:59 PM
> To: Luke Shepard
> Cc: [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Sun, 6 Jun 2010 17:10:26 -0700

I hope so.

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 7 Jun 2010 10:32:40 -0400

Thanks Dick.  I was just kinda confused: if the Assertion Flow was already in the WRAP draft and now in the core spec (OAuth2.0-draft-05), what do we gain from separating it off again.

/thomas/

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Sunday, June 06, 2010 8:10 PM
> To: Thomas Hardjono
> Cc: [email-masked]
> > Apologies for another newbie question: is the design-intention underlying
> the Assertion Flow in OAuth2.0-draft-05 the same as that in the WRAP draft
> (draft-hardt-oauth-01)?
> >
> > /thomas/
> >

---

From: Dick Hardt <[email-masked]>
Date: Mon, 7 Jun 2010 09:41:11 -0700

I would prefer to see it in the core spec.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 23:56:58 -0700

As long as:

- You can provide a URI identifier for the assertion format you are going to use, and
- The authorization server can do something useful with the assertion provided and decide if it should grant an access token

Then sure, you can use the assertion flow for utilizing any other trust framework for obtaining an access token.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lisa Dusseault
Sent: Wednesday, June 02, 2010 10:33 AM
To: oauth
Subject: [OAUTH-WG] Assertion flow and token bootstrapping

Any thoughts?

Thanks,
Lisa