Re: [OAUTH-WG] JWT Token on-behalf of Use case
Speaking as someone who is reasonably familiar with Kerberos and the general concepts involved, I find both Microsoft/Kerberos technology ((constrained delegation/protocol transition) and the ws-trust text horribly confusing and would recommend against all of the above as examples of clarity. After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not because there was clarity. This may be a case where new terminology is worthwhile if you can find something that multiple people (especially new readers not overly familiar with the concepts) find to be clear. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Token on-behalf of Use case
I'm just catching up on this tread, but would appreciate an in-room discussion on this topic that doesn't assume the adopted draft has the agreed upon approach as I am not reading that there is consensus on that approach in this thread at all. Could we see presentations on Mike's draft and Brian's? Justin, do you agree that Brian's draft covers the use case in our draft as was implied in this thread? I'd like to see a discussion guided by the chairs to see if we can find a go-forward plan. There seems to be differing opinions and maybe a pull towards simpler approaches that extend Oauth. Thank you. On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman hartmans-i...@mit.edu wrote: Speaking as someone who is reasonably familiar with Kerberos and the general concepts involved, I find both Microsoft/Kerberos technology ((constrained delegation/protocol transition) and the ws-trust text horribly confusing and would recommend against all of the above as examples of clarity. After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not because there was clarity. This may be a case where new terminology is worthwhile if you can find something that multiple people (especially new readers not overly familiar with the concepts) find to be clear. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Kathleen, I agree that Brian’s approach covers the use case that drove my original draft and effectively subsumes my approach. My standing contention with the document as it stands is and has always been that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I would love to see a productive conversation on this front. — Justin On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: I'm just catching up on this tread, but would appreciate an in-room discussion on this topic that doesn't assume the adopted draft has the agreed upon approach as I am not reading that there is consensus on that approach in this thread at all. Could we see presentations on Mike's draft and Brian's? Justin, do you agree that Brian's draft covers the use case in our draft as was implied in this thread? I'd like to see a discussion guided by the chairs to see if we can find a go-forward plan. There seems to be differing opinions and maybe a pull towards simpler approaches that extend Oauth. Thank you. On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman hartmans-i...@mit.edu mailto:hartmans-i...@mit.edu wrote: Speaking as someone who is reasonably familiar with Kerberos and the general concepts involved, I find both Microsoft/Kerberos technology ((constrained delegation/protocol transition) and the ws-trust text horribly confusing and would recommend against all of the above as examples of clarity. After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not because there was clarity. This may be a case where new terminology is worthwhile if you can find something that multiple people (especially new readers not overly familiar with the concepts) find to be clear. ___ OAuth mailing list OAuth@ietf.org mailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Token on-behalf of Use case
I’ll write a note later today describing how the just-published update that makes the Token Exchange draft token-type agnostic also enables it to be used in fully “OAuthy” cases – where some of the tokens used are OAuth access tokens or refresh tokens. (Right now I’m writing up the changes made to draft-ietf-oauth-proof-of-possession, then will get to the JWK Thumbprint and Token Exchange write-ups…) Cheers, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Tuesday, July 07, 2015 12:52 PM To: Kathleen Moriarty Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Kathleen, I agree that Brian’s approach covers the use case that drove my original draft and effectively subsumes my approach. My standing contention with the document as it stands is and has always been that it’s lacking a general syntactical approach and it isn’t very OAuth-y. I would love to see a productive conversation on this front. — Justin On Jul 7, 2015, at 3:43 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.commailto:kathleen.moriarty.i...@gmail.com wrote: I'm just catching up on this tread, but would appreciate an in-room discussion on this topic that doesn't assume the adopted draft has the agreed upon approach as I am not reading that there is consensus on that approach in this thread at all. Could we see presentations on Mike's draft and Brian's? Justin, do you agree that Brian's draft covers the use case in our draft as was implied in this thread? I'd like to see a discussion guided by the chairs to see if we can find a go-forward plan. There seems to be differing opinions and maybe a pull towards simpler approaches that extend Oauth. Thank you. On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman hartmans-i...@mit.edumailto:hartmans-i...@mit.edu wrote: Speaking as someone who is reasonably familiar with Kerberos and the general concepts involved, I find both Microsoft/Kerberos technology ((constrained delegation/protocol transition) and the ws-trust text horribly confusing and would recommend against all of the above as examples of clarity. After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not because there was clarity. This may be a case where new terminology is worthwhile if you can find something that multiple people (especially new readers not overly familiar with the concepts) find to be clear. ___ OAuth mailing list OAuth@ietf.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Token on-behalf of Use case
On Tue, Jul 7, 2015 at 3:43 PM, Kathleen Moriarty kathleen.moriarty.i...@gmail.com wrote: I'm just catching up on this tread, but would appreciate an in-room discussion on this topic that doesn't assume the adopted draft has the agreed upon approach as I am not reading that there is consensus on that approach in this thread at all. Could we see presentations on Mike's draft and Brian's? Justin, do you agree that Brian's draft covers the use case in our draft as was implied in this thread? s/our/your/ :-) I'd like to see a discussion guided by the chairs to see if we can find a go-forward plan. There seems to be differing opinions and maybe a pull towards simpler approaches that extend Oauth. Thank you. On Tue, Jul 7, 2015 at 3:18 PM, Sam Hartman hartmans-i...@mit.edu wrote: Speaking as someone who is reasonably familiar with Kerberos and the general concepts involved, I find both Microsoft/Kerberos technology ((constrained delegation/protocol transition) and the ws-trust text horribly confusing and would recommend against all of the above as examples of clarity. After several years I've finally gotten to a point where I understand the Kerberos terms, but that's simply by using them regularly, not because there was clarity. This may be a case where new terminology is worthwhile if you can find something that multiple people (especially new readers not overly familiar with the concepts) find to be clear. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Best regards, Kathleen -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:*
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token. On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case
Re: [OAUTH-WG] JWT Token on-behalf of Use case
The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 6, 2015 11:29 AM To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN linkhttps://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archivehttps://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to thathttps://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes, -- Mike
Re: [OAUTH-WG] JWT Token on-behalf of Use case
I keep providing links to MS documentation that leads one to a different conclusion for WIF. https://msdn.microsoft.com/en-us/library/ee748487.aspx https://msdn.microsoft.com/en-us/library/ee748487.aspx and https://msdn.microsoft.com/en-us/library/ee517269.aspx An ActAs RST element indicates that the requestor wants a token that contains claims about two distinct entities: the requestor, and an external entity represented by the token in the ActAs element. An OnBehalfOf RST element indicates that the requestor wants a token that contains claims only about one entity: the external entity represented by the token in the OnBehalfOf element. That reflects my understanding that prior to WS-Trust 1.4 OnBehalfOf was impersonation and in WS-Trust 1.4 was added to provide the composite assertion. The JBOS docs and examples are also consistent with this https://docs.jboss.org/author/display/JBWS/ActAs+WS-Trust+Scenario Or these: https://thilinamb.wordpress.com/2009/08/21/identity-delegation-in-ws-trust-1-4/ http://blogs.msdn.com/b/alikl/archive/2011/03/15/windows-identity-foundation-wif-the-difference-between-actas-and-onbehalfof.aspx?Redirected=true https://www.netiq.com/documentation/netiqaccessmanager4/identityserverhelp/data/ws-trust_usecases.html Given that you were one of the authors, you are as close to authoritative as one could get. However as far as I can tell there is some confusion that needs to be resolved. I agree we need the functionality of the two, and I don’t really care what they are called as long as we are not confusing developers. John B. On Jul 6, 2015, at 5:43 PM, Anthony Nadalin tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 6, 2015 11:29 AM To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential
Re: [OAUTH-WG] JWT Token on-behalf of Use case
I think the original reasoning was sound, but the fact that so many remain confused is good reason to go to new vocab. We could still have clarifying text that impersonate/composite is xxx and yyy in kerberos etc. Phil On Jul 6, 2015, at 13:43, Anthony Nadalin tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 6, 2015 11:29 AM To: Mike Jones michael.jo...@microsoft.com Cc: oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further
Re: [OAUTH-WG] JWT Token on-behalf of Use case
A natural usage of act-as or impersonation http://www.oxforddictionaries.com/us/definition/american_english/impersonate would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and on-behalf-of contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, *with* * on-behalf-of semantics, principal A still has its own identity* * separate from B and it is explicitly understood that while B may have* * delegated its rights to A, any actions taken are being taken by A and* * not B. In a sense, A is an agent for B.* On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. *When principal A* * impersonates principal B, then in so far as any entity receiving* * Claims is concerned, they are actually dealing with B. *It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Monday, July 6, 2015 11:29 AM *To:* Mike Jones michael.jo...@microsoft.com *Cc:* oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated
Re: [OAUTH-WG] JWT Token on-behalf of Use case
It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Monday, July 06, 2015 8:13 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft. His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation. I think Brian is closer in explaining it. In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations. I think many times it is how WIF implemented it that people copied. It may be better to have new terms that are clear such as impersonation and composite. The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics. There are plusses and minuses to both options. Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability. There are also issues around how this would work with proof of possession security tokens, both as input and output. Perhaps we can make some progress on this in Prague. John B. On Jul 6, 2015, at 11:04 AM, Brian Campbell bcampb...@pingidentity.com wrote: Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token. On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Mike, I have pointed this out several times. I understand that you disagree. The WS-Trust spec is not as clear as it could be. I included the MSDN note explaining how WIF interprets it. https://msdn.microsoft.com/en-us/library/ee748487.aspx Given that there seems to be differing opinions on the semantics beyond just me, can we agree that the terms are not as clear as one would hope? I may be wrong, but I suspect that I am not the only one. We can discuss it at the F2F. John B. On Jul 6, 2015, at 1:33 PM, Mike Jones michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Monday, July 06, 2015 8:13 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft. His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation. I think Brian is closer in explaining it. In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations. I think many times it is how WIF implemented it that people copied. It may be better to have new terms that are clear such as impersonation and composite. The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics. There are plusses and minuses to both options. Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability. There are also issues around how this would work with proof of possession security tokens, both as input and output. Perhaps we can make some progress on this in Prague. John B. On Jul 6, 2015, at 11:04 AM, Brian Campbell bcampb...@pingidentity.com wrote: Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token. On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Monday, July 06, 2015 8:13 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft. His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation. I think Brian is closer in explaining it. In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations. I think many times it is how WIF implemented it that people copied. It may be better to have new terms that are clear such as impersonation and composite. The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics. There are plusses and minuses to both options. Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability. There are also issues around how this would work with proof of possession security tokens, both as input and output. Perhaps we can make some progress on this in Prague. John B. On Jul 6, 2015, at 11:04 AM, Brian Campbell bcampb...@pingidentity.com wrote: Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Fair enough, Brian. For clarity, my sense of the action items is that I agreed to do those actions based on feedback at the ad-hoc meeting and then people would review the result – not that everything would be “done” after taking those actions. I’ll still plan to act on that feedback. I’d be glad to sit down with you and others in Prague, Brian, to work out how to make sure your use cases are covered and the draft is as clear as it can be, given its somewhat esoteric subject matter. Now that JWT and JOSE and the OAuth Assertions specs are done and several others are nearly done, getting back to this is a priority for me. Cheers, -- Mike From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 06, 2015 11:29 AM To: Mike Jones Cc: John Bradley; oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN linkhttps://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archivehttps://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to thathttps://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes, -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Monday, July 06, 2015 8:13 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft. His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation. I think Brian is closer in explaining it. In fairness because WS-Trust
Re: [OAUTH-WG] JWT Token on-behalf of Use case
+1 for this. Let's learn from the mistakes of the past instead of repeating them. We've always done it this way is a really, really poor reason for doing something. -- Justin On 7/6/2015 5:20 PM, Phil Hunt wrote: I think the original reasoning was sound, but the fact that so many remain confused is good reason to go to new vocab. We could still have clarifying text that impersonate/composite is xxx and yyy in kerberos etc. Phil On Jul 6, 2015, at 13:43, Anthony Nadalin tony...@microsoft.com mailto:tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Monday, July 6, 2015 11:29 AM *To:* Mike Jones michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com *Cc:* oauth oauth@ietf.org mailto:oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas
Re: [OAUTH-WG] JWT Token on-behalf of Use case
What is written in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and the text that describes the Windows Kerberos support for Protocol Transition and Constrained Delegation are in alignment not sure what make you think they are not. If you are trying to describe different features than Windows Kerberos Protocol Transition/Constrained Delegation that then I would agree that the text may not be correct but then again it would not be describing the Windows Kerberos Protocol Transition/Constrained Delegation. The way you have the text describes different set use case then what the feature of https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 describes. From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 6, 2015 2:33 PM To: Anthony Nadalin tony...@microsoft.com Cc: Mike Jones michael.jo...@microsoft.com; oauth oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case A natural usage of act-as or impersonationhttp://www.oxforddictionaries.com/us/definition/american_english/impersonate would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and on-behalf-of contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. When principal A impersonates principal B, then in so far as any entity receiving Claims is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin tony...@microsoft.commailto:tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. From: OAuth [mailto:oauth-boun...@ietf.orgmailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell Sent: Monday, July 6, 2015 11:29 AM To: Mike Jones michael.jo...@microsoft.commailto:michael.jo...@microsoft.com Cc: oauth oauth@ietf.orgmailto:oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN linkhttps://msdn.microsoft.com
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Sorry Mike, I was looking at an earlier version that had them reversed. I think the wording can be improved but the composite vs delegation semantic is correct now. However Tony now seems to disagree with that. I am going to walk away slowly and let you sort out his last post:) We can discuss further in Prague. John B. On Jul 6, 2015, at 3:48 PM, Mike Jones michael.jo...@microsoft.com wrote: Fair enough, Brian. For clarity, my sense of the action items is that I agreed to do those actions based on feedback at the ad-hoc meeting and then people would review the result – not that everything would be “done” after taking those actions. I’ll still plan to act on that feedback. I’d be glad to sit down with you and others in Prague, Brian, to work out how to make sure your use cases are covered and the draft is as clear as it can be, given its somewhat esoteric subject matter. Now that JWT and JOSE and the OAuth Assertions specs are done and several others are nearly done, getting back to this is a priority for me. Cheers, -- Mike From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Monday, July 06, 2015 11:29 AM To: Mike Jones Cc: John Bradley; oauth Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head a little every-time I read it but does seems to confuse things. The MSDN link https://msdn.microsoft.com/en-us/library/ee748487.aspx John gave is much more to the point than WS-Trust (I don't believe WS-Trust can be pointed to as a model of clarity). In the draft I wrote, I tried to take Mike's text and clarify a distinction between impersonation and delegation with https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-1.3 and then also be very explicit about act-as vs. on-behalf-of in the parameter definitions at https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 https://tools.ietf.org/html/draft-campbell-oauth-sts-01#section-2 in a manor that was consistent with WS-Trust and the MSDN explanation. I could see value in breaking with that shaky legacy and using new terms too. But I get the point of trying to keep with the old also and potential for even more confusing by using new terms. I wrote draft-campbell-oauth-sts last year in response to the call for adoption of jones-oauth-token-exchange (thread from the archive https://www.ietf.org/mail-archive/web/oauth/current/msg13305.html). Though I didn't try and stand in the way and indicated a willingness to collaborate on things. With the expectation, of course, that the details would differ from the -00s and -01s as work progressed. Folks seemed generally amenable to that https://www.ietf.org/mail-archive/web/oauth/current/msg13308.html at the time but little has happened since then. Phil's earlier point about the priory of this getting pushed down has some truth to it. But I still believe it's something that can provide a lot of value in standardizing, if we do so in a reasonable way. On Mon, Jul 6, 2015 at 10:33 AM, Mike Jones michael.jo...@microsoft.com mailto:michael.jo...@microsoft.com wrote: It would surprise me if on-behalf-of and act-as were reversed with respect WS-Trust, because the explanations of the terms came directly from WS-Trust 1.4. I also think the chances of us reducing confusion by inventing new terminology, rather than adding to it, would not be in our favor. :-/ FYI, the action items outstanding from our ad-hoc meeting on this draft in Dallas are: - Allowing security types other than JWT to also be used as the act_as and on_behalf_of request values. - Further integrating the mechanism into the existing OAuth ecosystem - allowing use of access tokens or refresh tokens when appropriate. I plan to do the first today. The second is probably more than I'll get done today before the submission cutoff. I agree with John that it would be useful to have discussions on this in Prague on the best way to achieve this further integration. I'll plan to come into the Prague meeting with a concrete proposal for review. Best wishes
Re: [OAUTH-WG] JWT Token on-behalf of Use case
That doesn't even make sense. On Mon, Jul 6, 2015 at 3:56 PM, Anthony Nadalin tony...@microsoft.com wrote: What is written in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 and the text that describes the Windows Kerberos support for Protocol Transition and Constrained Delegation are in alignment not sure what make you think they are not. If you are trying to describe different features than Windows Kerberos Protocol Transition/Constrained Delegation that then I would agree that the text may not be correct but then again it would not be describing the Windows Kerberos Protocol Transition/Constrained Delegation. The way you have the text describes different set use case then what the feature of https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 describes. *From:* Brian Campbell [mailto:bcampb...@pingidentity.com] *Sent:* Monday, July 6, 2015 2:33 PM *To:* Anthony Nadalin tony...@microsoft.com *Cc:* Mike Jones michael.jo...@microsoft.com; oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case A natural usage of act-as or impersonation http://www.oxforddictionaries.com/us/definition/american_english/impersonate would suggest, to many people anyway, that the way you just used the terms is reversed. The bold text below from https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 uses 'impersonates' and on-behalf-of contrary to what you just wrote about Windows Kerb. That's where the assertion that the draft has them reversed from de facto usage in WS-Trust. Those semantics are not only one open issue that needs to be resolved, however, even if they occupy most of the discussion. 1.3. On-Behalf-Of vs. Impersonation Semantics When principal A acts on behalf of principal B, A is given all the rights that B has within some defined rights context. Whereas, *with* * on-behalf-of semantics, principal A still has its own identity* * separate from B and it is explicitly understood that while B may have* * delegated its rights to A, any actions taken are being taken by A and* * not B. In a sense, A is an agent for B.* On-behalf-of semantics are therefore different than impersonation semantics, with which it is sometimes confused. *When principal A* * impersonates principal B, then in so far as any entity receiving* * Claims is concerned, they are actually dealing with B. *It is true that some members of the identity system might have awareness that impersonation is going on but it is not a requirement. For all intents and purposes, when A is acting for B, A is B. On Mon, Jul 6, 2015 at 2:43 PM, Anthony Nadalin tony...@microsoft.com wrote: The WS-Trust “ActAs” mimics the Windows Kerberos Protocol Transition (impersonation) feature as this enables an account to impersonate another account for the purpose of providing access to resources. In a typical scenario, the impersonating account would be a service account assigned to a web application or the computer account of a web server. The impersonated account would be a user account requiring access to resources (e.g. data in an SQL database) via a web application. In this scenario, SQL server would be accessed by the impersonating (service account) account, however access would be under the context of the impersonated (user) account. WS-Trust “OnBehalfOf” mimics the Windows Kerberos Constrained Delegation feature, which lets you limit the back-end services for which a front-end service can request tickets on behalf of another user. “OnBehalfOf” allows a selected services on a server can be granted for access by the impersonating account, whilst other services on the same server, or services on other servers are denied for access. Maybe someone can summarize why they think the text for ActAs and OnBehalfOf in WS-Trust or Windows Kerberos is wrong or swapped as I have not seen a clear explanation other than John saying that Brian knows and Brian saying John knows. Our usage and use cases are based upon the deployed services of WS-Trust and Kerberos support in Windows (workstation and server) and Xbox. *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Brian Campbell *Sent:* Monday, July 6, 2015 11:29 AM *To:* Mike Jones michael.jo...@microsoft.com *Cc:* oauth oauth@ietf.org *Subject:* Re: [OAUTH-WG] JWT Token on-behalf of Use case Stating specific action items resulting from the ad-hoc meeting in Dallas like that suggests some clear consensus was reached, which is not at all the case. As I recall, several of us argued past one another for an hour or so and decided to adjourn in order to go to the bar (okay, and dinner too - but mostly beer). The impression about reversal of terms, I think, comes from the text in https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01#section-1.3 which hurts my head
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Yes unfortunately we haven’t made any progress on this since accepting Mike’s first draft. His proposal is basically for a new endpoint while Brian tired to fit it into the existing token endpoint. I think draft-ietf-oauth-token-exchange-01 still has OnBehalfOf and ActAs reversed compared to WS-Trust 1.4. see https://msdn.microsoft.com/en-us/library/ee748487.aspx for the short explanation. I think Brian is closer in explaining it. In fairness because WS-Trust originally only had On-Behalf-Of the naming and what people put in tokens is a bit muddled in many implementations. I think many times it is how WIF implemented it that people copied. It may be better to have new terms that are clear such as impersonation and composite. The WG needs to decide if this is going to be an entirely new endpoint, free of the Token endpoint semantics. There are plusses and minuses to both options. Also while it is nice to be pure and talk about abstract security tokens, it would be good to give some guidance on what a composite security token would look like for interoperability. There are also issues around how this would work with proof of possession security tokens, both as input and output. Perhaps we can make some progress on this in Prague. John B. On Jul 6, 2015, at 11:04 AM, Brian Campbell bcampb...@pingidentity.com wrote: Thanks Sergey, The goal of draft-campbell-oauth-sts was to be consistent with OAuth 2.0 and thus hopefully familiar to developers and easy to understand and implement (especially from the client side). It's also intended to be flexible in order to accommodate a variety of use-cases including the chaining type cases that Justin's draft covers. Specifying a security_token_type of the returned token is just a way of providing more info to the client about the token (i.e. is this a JWT or a SAML token or something else) via a URI. It's not always needed but in STS style cases the tokens are not always opaque to the client and the parameter just provides info about the returned token. On Mon, Jul 6, 2015 at 5:33 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Brian I've read the text, I like it is still pure OAuth2, with few extra parameters added to the access token request, and a key response property being 'access_token' as opposed to 'security_access_token' as in the draft-ietf-oauth-token-exchange-01. It appears draft-campbell-oauth-sts-01 can cover a draft-richer-oauth-chain-00 case with the on_behalf_of (and/or act_as ?) property being an original client token but not 100% sure given draft-richer-oauth-chain-00 covers a specific case. One thing I'm not sure about is what is the purpose of specifying a security_token_type of the returned access token Thanks, Sergey On 01/07/15 15:59, Brian Campbell wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com mailto:sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Not quite, the actual tokens are still opaque, the requestor is just asking for a token exchange , the requestor can specify the requested token type it's up to the server to determine the actual token it will delever -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, July 1, 2015 5:18 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] JWT Token on-behalf of Use case As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That's what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust -1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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] JWT Token on-behalf of Use case
Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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] JWT Token on-behalf of Use case
Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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] JWT Token on-behalf of Use case
As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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] JWT Token on-behalf of Use case
One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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] JWT Token on-behalf of Use case
After putting out the original proposal, I am not totally sure we need it. In many cases we architected around the issue. https://tools.ietf.org/html/draft-hunt-oauth-chain-01 Question is token swap for cross domain chaining? Shouldn't in domain servers be acting on internal policy mechanisms? Is there an interop need for the internal case? I conclude this is a primarily a cross domain case that could also be used in internally. But internal is not the driver. Based on the number of submissions, this seems to be a 1% case that everyone has. Unfortunately that means we keep downgrading its priority. Phil On Jul 1, 2015, at 07:59, Brian Campbell bcampb...@pingidentity.com wrote: One problem, I think, with token exchange is that it can be really simple (token in and token out) and really complicated (client X wants a token that says user A is doing something on behalf of user B) at the same time. I put forth https://tools.ietf.org/html/draft-campbell-oauth-sts-01 in an attempt to simplify things and express what I envisioned as an OAuth based token exchange framework. Though it likely only muddied the waters :) On Wed, Jul 1, 2015 at 7:07 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi Justin https://tools.ietf.org/html/draft-richer-oauth-chain-00 is much easier to read, that I can tell for sure, at least it is obvious why a given entity (RS1) may want to exchange the current token provided by a client for a new token. Definitely easily implementable... One thing I'm not sure in the draft-richer-oauth-chain-00 about is on behalf of whose entity RS1 will be acting once it starts accessing RS2, On Behalf Of RO, or may be On Behalf Of (RO + Client), or may be it is On Behalf Of RO + Act As Client ? The last one seems most logical to me... Thanks, Sergey On 01/07/15 13:18, Justin Richer wrote: As it's written right now, it's a translation of some WS-* concepts into JWT format. It's not really OAuth-y (since the client has to understand the token format along with everyone else, and according to the authors the artifacts might not even be OAuth tokens), and that's my main issue with the document. Years ago, I proposed an OAuth-based token swap mechanism: https://tools.ietf.org/html/draft-richer-oauth-chain-00 This works without defining semantics of the tokens themselves, just like the rest of OAuth. I've proposed to the authors of the current draft that it should incorporate both semantic (using JWT) and syntactic (using a simple token-agnostic grant) token swap mechanisms, and that the two could be easily compatible. -- Justin On 7/1/2015 6:35 AM, Sergey Beryozkin wrote: Hmm... perhaps the clue is in the draft title, token-exchange, so may be it is a case of the given access token (on_behalf_of or act_as claim) being used to request a new security token. One can only guess though, does not seem like the authors are keen to answer the newbie questions... Cheers, Sergey On 30/06/15 13:38, Sergey Beryozkin wrote: Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JWT Token on-behalf of Use case
Hi, Can you please explain what is the difference between On-Behalf-Of semantics described in the draft-ietf-oauth-token-exchange-01 and the implicit On-Behalf-Of semantics a client OAuth2 token possesses ? For example, draft-ietf-oauth-token-exchange-01 mentions: Whereas, with on-behalf-of semantics, principal A still has its own identity separate from B and it is explicitly understood that while B may have delegated its rights to A, any actions taken are being taken by A and not B. In a sense, A is an agent for B. This is a typical case with the authorization code flow where a client application acts on-behalf-of the user who authorized this application ? Sorry if I'm missing something Cheers, Sergey On 25/06/15 22:28, Mike Jones wrote: That’s what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike *From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) *Sent:* Thursday, June 25, 2015 2:20 PM *To:* OAuth@ietf.org *Subject:* [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Of http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, CISSP *Cisco Systems, Inc http://www.cisco.com/* *Bldg. J, San Jose, USA,* *Phone: +1 408 527 9176* ___ 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] JWT Token on-behalf of Use case
That's what https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-01 is about. Cheers, -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vivek Biswas -T (vibiswas - XORIANT CORPORATION at Cisco) Sent: Thursday, June 25, 2015 2:20 PM To: OAuth@ietf.org Subject: [OAUTH-WG] JWT Token on-behalf of Use case Hi All, I am looking to solve a use-case similar to WS-Security On-Behalf-Ofhttp://docs.oasis-open.org/ws-sx/ws-trust/v1.4/errata01/os/ws-trust-1.4-errata01-os-complete.html#_Toc325658980 with OAuth JWT Token. Is there a standard claim which we can define within the OAuth JWT which denote the On-behalf-of User. For e.g., a Customer Representative trying to create token on behalf of a customer and trying to execute services specific for that specific customer. Regards, Vivek Biswas, [CISSP] Cisco Systems, Inchttp://www.cisco.com/ Bldg. J, San Jose, USA, Phone: +1 408 527 9176 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
