Re: [OAUTH-WG] Assertion flow and token bootstrapping
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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Lisa Dusseault Sent: Wednesday, June 02, 2010 10:33 AM 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
I would prefer to see it in the core spec. On 2010-06-07, at 7:32 AM, Thomas Hardjono wrote: > 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/ > > __ > > >> -Original Message- >> From: Dick Hardt [mailto:dick.ha...@gmail.com] >> Sent: Sunday, June 06, 2010 8:10 PM >> To: Thomas Hardjono >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >> >> I hope so. >> >> On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote: >> >>> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>>> Dick Hardt >>>> Sent: Friday, June 04, 2010 9:59 PM >>>> To: Luke Shepard >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >>>> >>>> because we use it >>>> >>>> On 2010-06-04, at 6:40 PM, Luke Shepard wrote: >>>> >>>>> Why? >>>>> >>>>> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Jun 4, 2010, at 5:38 PM, Brian Campbell >>>>>> wrote: >>>>>> >>>>>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>>>>>> wrote: >>>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> I'd like to see the assertion flow remain in the base spec. >>>>>>> ___ >>>>>>> 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 > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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/ __ > -Original Message- > From: Dick Hardt [mailto:dick.ha...@gmail.com] > Sent: Sunday, June 06, 2010 8:10 PM > To: Thomas Hardjono > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping > > I hope so. > > On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote: > > > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > >> Dick Hardt > >> Sent: Friday, June 04, 2010 9:59 PM > >> To: Luke Shepard > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping > >> > >> because we use it > >> > >> On 2010-06-04, at 6:40 PM, Luke Shepard wrote: > >> > >>> Why? > >>> > >>> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > >>> > >>>> +1 > >>>> > >>>> Sent from my iPhone > >>>> > >>>> On Jun 4, 2010, at 5:38 PM, Brian Campbell > >>>> wrote: > >>>> > >>>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre > >>>>> wrote: > >>>>>> > >>>>>> 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. > >>>>> > >>>>> > >>>>> I'd like to see the assertion flow remain in the base spec. > >>>>> ___ > >>>>> 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
I hope so. On 2010-06-06, at 3:22 PM, Thomas Hardjono wrote: > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >> Dick Hardt >> Sent: Friday, June 04, 2010 9:59 PM >> To: Luke Shepard >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping >> >> because we use it >> >> On 2010-06-04, at 6:40 PM, Luke Shepard wrote: >> >>> Why? >>> >>> On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: >>> >>>> +1 >>>> >>>> Sent from my iPhone >>>> >>>> On Jun 4, 2010, at 5:38 PM, Brian Campbell >>>> wrote: >>>> >>>>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>>>> wrote: >>>>>> >>>>>> 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. >>>>> >>>>> >>>>> I'd like to see the assertion flow remain in the base spec. >>>>> ___ >>>>> 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Dick Hardt > Sent: Friday, June 04, 2010 9:59 PM > To: Luke Shepard > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Assertion flow and token bootstrapping > > because we use it > > On 2010-06-04, at 6:40 PM, Luke Shepard wrote: > > > Why? > > > > On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > > > >> +1 > >> > >> Sent from my iPhone > >> > >> On Jun 4, 2010, at 5:38 PM, Brian Campbell > >> wrote: > >> > >>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre > >>> wrote: > >>>> > >>>> 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. > >>> > >>> > >>> I'd like to see the assertion flow remain in the base spec. > >>> ___ > >>> 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
because we use it On 2010-06-04, at 6:40 PM, Luke Shepard wrote: > Why? > > On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > >> +1 >> >> Sent from my iPhone >> >> On Jun 4, 2010, at 5:38 PM, Brian Campbell >> wrote: >> >>> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >>> wrote: 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. >>> >>> >>> I'd like to see the assertion flow remain in the base spec. >>> ___ >>> 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
Why? On Jun 4, 2010, at 4:41 PM, Patrick Harding wrote: > +1 > > Sent from my iPhone > > On Jun 4, 2010, at 5:38 PM, Brian Campbell > wrote: > >> On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre >> wrote: >>> >>> 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. >> >> >> I'd like to see the assertion flow remain in the base spec. >> ___ >> 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
+1 Sent from my iPhone On Jun 4, 2010, at 5:38 PM, Brian Campbell wrote: On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: 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. I'd like to see the assertion flow remain in the base spec. ___ 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
+1 Am 04.06.2010 23:38, schrieb Brian Campbell: On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: 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. I'd like to see the assertion flow remain in the base spec. ___ 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
On Thu, Jun 3, 2010 at 9:20 AM, Peter Saint-Andre wrote: > > 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. I'd like to see the assertion flow remain in the base spec. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
On 2010-06-03, at 8:20 AM, Peter Saint-Andre wrote: > On 6/3/10 8:54 AM, Thomas Hardjono wrote: > >> 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. > > 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. 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. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
On 2010-06-03, at 7: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). It can be used with any tokens. I use the STS term to clarify the design pattern. > > - Also, is it the expectation that a "profile" of OAuth2.0 > be created to address certain use-cases. Such as? > > 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. 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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 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 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
On 6/3/10 8:54 AM, Thomas Hardjono wrote: > 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. 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/ smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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 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 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 > no
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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: 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
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 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 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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 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
Re: [OAUTH-WG] Assertion flow and token bootstrapping
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
