Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense. And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
Hi Brian, we should definitely take your work into account and I recall some other drafts on the same subject being published some time ago as well. Adding more co-authors to this working group item makes a lot of sense to me. Ciao Hannes On 08/11/2014 04:42 PM, Brian Campbell wrote: I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense. And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision. signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
I read the draft and just don’t get it, it overloads some of the basic semantics, I’m not quite sure you get the concept of token exchange, has what you described been deployed ? or even built ? From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, August 11, 2014 7:42 AM To: Mike Jones Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item I'd be okay with that as a way forward. Frankly, of course, I'd prefer to see draft-campbell-oauth-sts as the starting point with Mike and the other draft-jones-oauth-token-exchange authors added as co-authors. Regardless, there are elements from both that likely need to end up in the final work so a consolidation of authors and concepts makes sense. And yes, there are lots of details that the working group will need to decide on going forward that we shouldn't get hung up on right now. Though I believe that deciding if the token endpoint is used for general token exchange is an important philosophical question that should be answered first. If the token endpoint is to be used, I strongly belie that this token exchange should leverage and work within the constructs provided and defined by OAuth. That's the direction I took with draft-campbell-oauth-sts and yes that involves overloading the access_token response parameter with something that's not always strictly an access token. The existing token endpoint request/response are already rather close to what one might expect in an STS type exchange. I find there's a nice elegant simplicity to it but I also see where that discomfort might come from. If there's consensus to not use/overload the existing stuff, I think it'd be much more appropriate to define a new endpoint. A lot of syntactic stuff likely falls out from that decision. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
I am very much in favor of the WG pursuing the general concept of an OAuth Token Exchange. However, I don't believe this document, in its current form anyway, is the necessarily the most appropriate starting point as a WG work item. I wrote up an I-D, which I'd ask to be considered as alternative or additional input into the process: https://datatracker.ietf.org/doc/draft-campbell-oauth-sts/ I don't intend this to be confrontational or this is better than that kind of thing. Producing a draft just seemed like the most straightforward way to document some initial thoughts on it. I'm more than open to collaborating on it going forward. On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the OAuth 2.0 Token Exchange (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- [image: Ping Identity logo] https://www.pingidentity.com/ Brian Campbell Distinquished Engineer @ bcampb...@pingidentity.com [image: phone] +1 720.317.2061 Connect with us… [image: twitter logo] https://twitter.com/pingidentity [image: youtube logo] https://www.youtube.com/user/PingIdentityTV [image: LinkedIn logo] https://www.linkedin.com/company/21870 [image: Facebook logo] https://www.facebook.com/pingidentitypage [image: Google+ logo] https://plus.google.com/u/0/114266977739397708540 [image: slideshare logo] http://www.slideshare.net/PingIdentity [image: flipboard logo] http://flip.it/vjBF7 [image: rss feed icon] https://www.pingidentity.com/blogs/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
Thanks for doing that. I think that this is clearer and extends Mike's draft to be more specific about input and output token types. It is going to be hard for people to get their heads around this without at-least having some example use-cases and example token input and outputs. In following this proposed model would code and refresh tokens be considered valid on_behalf_of tokens? I am guessing that a JWT or SAML 2 assertion clearly can be. So if for example I wanted a JWT/id_token to use in the assertion flow at a SaaS I would send. aud = an identifyer for the SaaS AS (perhaps the token endpoint or issuer uri) requested_security_token_type = urn:ietf:params:oauth:token-type:jwt (perhaps something more specific?) on_behalf_of = (refresh token?) on_behalf_of_token_type = urn:ietf:params:oauth:token-type:refresh (yes I just made that up) So how might sending an act_as token to the token endpoint as part of the request impact the result. Do you see the act_as interacting with PoP to limit who can present the resulting token. Is act_as simply duplicating the authentication portion of the current assertion profile? Not having concrete answers at this point is not a problem, but we do need to think all of this through. I think this document is also useful input. John B. On Aug 8, 2014, at 10:27 AM, Brian Campbell bcampb...@pingidentity.com wrote: I am very much in favor of the WG pursuing the general concept of an OAuth Token Exchange. However, I don't believe this document, in its current form anyway, is the necessarily the most appropriate starting point as a WG work item. I wrote up an I-D, which I'd ask to be considered as alternative or additional input into the process: https://datatracker.ietf.org/doc/draft-campbell-oauth-sts/ I don't intend this to be confrontational or this is better than that kind of thing. Producing a draft just seemed like the most straightforward way to document some initial thoughts on it. I'm more than open to collaborating on it going forward. On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the OAuth 2.0 Token Exchange (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes Derek ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Brian Campbell Distinquished Engineer @ bcampb...@pingidentity.com +1 720.317.2061 Connect with us… ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
Absolutely agree that some examples are needed. There's a [[ TODO ]] in there for it. I just hadn't gotten to it yet and wanted to get the I-D up before the Aug 10 date that Hannes put out there. The example you outlined is a good start, I think. Yes, code and refresh tokens would/could be valid tokens. A previously issued access token might also be. JWT SAML too. The last paragraph of http://tools.ietf.org/html/draft-campbell-oauth-sts-00#section-1 attempts to state that the scope of the doc is only the framework for exchange and that the syntax, semantics and security characteristics of the tokens themselves (both those presented to the are explicitly out of scope. What constitutes a valid token will depend on the deployment or additional profiling. So how might sending an act_as token to the token endpoint as part of the request impact the result. - in general I was thinking it'd result in an azp claim or something like that in the returned token. Do you see the act_as interacting with PoP to limit who can present the resulting token. - Quite possibly. Though, honestly, I don't yet have a complete concept of how PoP works in conjunction with all this. Is act_as simply duplicating the authentication portion of the current assertion profile? - there is potential for duplication in some cases, yes. But the motivation for act_as was to give additional flexibility by allowing an additional party to be represented. Also to try and align with draft-jones-oauth-token-exchange http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ to the extent possible. I had toyed with the idea of only having one inbound token for the subject and having the client (relying on client authentication) be the actor. Then maybe a flag to indicate if delegation vs impersonation is deserted in the returned token. But it seemed like there was a need (things you'd said among others) for more than two parties to be represented. There's some refinement to be done for sure though. Not having concrete answers at this point is not a problem, but we do need to think all of this through. - agree I think this document is also useful input. - thanks ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
First, I’ll say that I appreciate Brian also working on this topic. This is important for many multi-actor use cases and it would be good for OAuth to develop a standard in this area. I also agree with the discussion on the list that having some use case descriptions and concrete examples could help developers know how to do token exchange in an interoperable way. We should do that going forward. I just skimmed through Brian’s document. I agree with the thrust of a lot of. Much of it is equivalent to parts of draft-jones-oauth-token-exchange – albeit with different syntax. However, it seems to be missing the ability to represent statements about who is eligible to act for who, as is enabled by http://tools.ietf.org/html/draft-jones-oauth-token-exchange-01#section-4. Also, I’m not sure I’m comfortable overloading the access_token Token Endpoint response to convey the returned security token, since in the general case, the security token is not an access token. All of those are the kinds of details that the working group will get to decide on, so I’m not all that hung up on them right now. As a way forward, I’d actually propose that we accept draft-jones-oauth-token-exchange as a starting point for the working group document – as the hum in Toronto seemed to say that we would – but that we add Brian as a co-author of it. I’m comfortable working with Brian as a co-editor and we have a good track record of doing productive work together – including the nearly finished OAuth Assertions specifications. I’d also privately communicated to Brian that I see my current document as a starting point for the work and not something in final form and that I’d be happy to work with him to make sure that his use cases are accommodated and that it’s clear to developers how and when to use token exchange. Best wishes, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Friday, August 08, 2014 10:55 AM To: John Bradley Cc: oauth-cha...@tools.ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item Absolutely agree that some examples are needed. There's a [[ TODO ]] in there for it. I just hadn't gotten to it yet and wanted to get the I-D up before the Aug 10 date that Hannes put out there. The example you outlined is a good start, I think. Yes, code and refresh tokens would/could be valid tokens. A previously issued access token might also be. JWT SAML too. The last paragraph of http://tools.ietf.org/html/draft-campbell-oauth-sts-00#section-1 attempts to state that the scope of the doc is only the framework for exchange and that the syntax, semantics and security characteristics of the tokens themselves (both those presented to the are explicitly out of scope. What constitutes a valid token will depend on the deployment or additional profiling. So how might sending an act_as token to the token endpoint as part of the request impact the result. - in general I was thinking it'd result in an azp claim or something like that in the returned token. Do you see the act_as interacting with PoP to limit who can present the resulting token. - Quite possibly. Though, honestly, I don't yet have a complete concept of how PoP works in conjunction with all this. Is act_as simply duplicating the authentication portion of the current assertion profile? - there is potential for duplication in some cases, yes. But the motivation for act_as was to give additional flexibility by allowing an additional party to be represented. Also to try and align with draft-jones-oauth-token-exchangehttp://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ to the extent possible. I had toyed with the idea of only having one inbound token for the subject and having the client (relying on client authentication) be the actor. Then maybe a flag to indicate if delegation vs impersonation is deserted in the returned token. But it seemed like there was a need (things you'd said among others) for more than two parties to be represented. There's some refinement to be done for sure though. Not having concrete answers at this point is not a problem, but we do need to think all of this through. - agree I think this document is also useful input. - thanks ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
OK so act_as if not sent is implicitly the requestor perhaps authenticated by the endpoint in the normal OAuth way. If the if the requestor is acting like a proxy as in the Token Agent case the act_as would indicate the identity of the client making the request to the Token Agent so that the resulting token can include that identity as the AZA. I think that logic holds together. In that case, if the resulting token is PoP, then the party identified by the act_as's public key would go in the resulting token. That may actually be reversed from the WS-Trust usage, but that is something else to dig into in the WG. I think working on this along side of the PoP drafts will help prevent possible conflicts and confusions. We should accept Mikes draft or both of these as a starting point. John B. On Aug 8, 2014, at 1:55 PM, Brian Campbell bcampb...@pingidentity.com wrote: Absolutely agree that some examples are needed. There's a [[ TODO ]] in there for it. I just hadn't gotten to it yet and wanted to get the I-D up before the Aug 10 date that Hannes put out there. The example you outlined is a good start, I think. Yes, code and refresh tokens would/could be valid tokens. A previously issued access token might also be. JWT SAML too. The last paragraph of http://tools.ietf.org/html/draft-campbell-oauth-sts-00#section-1 attempts to state that the scope of the doc is only the framework for exchange and that the syntax, semantics and security characteristics of the tokens themselves (both those presented to the are explicitly out of scope. What constitutes a valid token will depend on the deployment or additional profiling. So how might sending an act_as token to the token endpoint as part of the request impact the result. - in general I was thinking it'd result in an azp claim or something like that in the returned token. Do you see the act_as interacting with PoP to limit who can present the resulting token. - Quite possibly. Though, honestly, I don't yet have a complete concept of how PoP works in conjunction with all this. Is act_as simply duplicating the authentication portion of the current assertion profile? - there is potential for duplication in some cases, yes. But the motivation for act_as was to give additional flexibility by allowing an additional party to be represented. Also to try and align with draft-jones-oauth-token-exchange to the extent possible. I had toyed with the idea of only having one inbound token for the subject and having the client (relying on client authentication) be the actor. Then maybe a flag to indicate if delegation vs impersonation is deserted in the returned token. But it seemed like there was a need (things you'd said among others) for more than two parties to be represented. There's some refinement to be done for sure though. Not having concrete answers at this point is not a problem, but we do need to think all of this through. - agree I think this document is also useful input. - thanks smime.p7s Description: S/MIME cryptographic signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Confirmation: Call for Adoption of OAuth 2.0 Token Exchange as an OAuth Working Group Item
Hi all, during the IETF #90 OAuth WG meeting, there was strong consensus in adopting the OAuth 2.0 Token Exchange (draft-jones-oauth-token-exchange-01.txt) specification as an OAuth WG work item. We would now like to verify the outcome of this call for adoption on the OAuth WG mailing list. Here is the link to the document: http://datatracker.ietf.org/doc/draft-jones-oauth-token-exchange/ If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion as to the suitability of adopting this document as a WG work item, please send mail to the OAuth WG list indicating your opinion (Yes/No). The confirmation call for adoption will last until August 10, 2014. If you have issues/edits/comments on the document, please send these comments along to the list in your response to this Call for Adoption. Ciao Hannes Derek signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
