Re: [OAUTH-WG] [External Sender] Re: Transaction Tokens issuance in the absence of incoming token

[Kai Lehmann <[e-mail]>]

Hi,

Sorry for replying to this so late to this thread. Although self-signed JWTs may help to fill the subject_token for Token Exchange, I think it can be a burden for the Workload presenting the Self signed JWT as well as for the Txn Token Service to validate that token. It would require the Workload to do generate and maintain proper signing key material – including rotating those keys on a regular basis as well as making them available to the Txn Token Service. Workloads may not have the capability to serve a JKWS file as they are purely operating in a backend environment (batch processes).

As this discussion is more or less already concluded, I hope that the spec can at least allow alternatives.

BR,
Kai


From: George Fletcher <george.fletcher=[e-mail]>
Date: Friday, 12. April 2024 at 19:53
To: Atul Tulshibagwale <[e-mail]>
Cc: Brian Campbell <[e-mail]>, Kai Lehmann <[e-mail]>, Dmitry Telegin <[e-mail]>, oauth <[e-mail]>
Subject: Re: [External Sender] Re: [OAUTH-WG] Transaction Tokens issuance in the absence of incoming token

Atul has submitted this PR to address this issue.
https://github.com/oauth-wg/oauth-transaction-tokens/pull/90

On Fri, Apr 12, 2024 at 12:10 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
Thanks all, for your input. We discussed alternatives on a call last week<https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/BkdOgipkA__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSUvjiHD$>, and arrived at using self-signed tokens with token exchange as a way forward.

On Fri, Apr 5, 2024 at 10:58 AM Brian Campbell <[e-mail]<mailto:[e-mail]>> wrote:
One potential benefit of keeping the use of Token Exchange is that some AS products/implementations have built a fair amount of configurability and extensibility into their Token Exchange support, which might allow for existing systems to be set up to do Transaction Tokens. Whereas a new endpoint or new grant type are more likely to require code changes to the core AS. Obviously this isn't universally true but something to consider nonetheless.

On Fri, Apr 5, 2024 at 4:13 AM Kai Lehmann <kai.lehmann=[e-mail]<mailto:[e-mail]>> wrote:
Hi,

that is my thought as well. It does not necessarily be a Token Exchange profile, but the Token endpoint makes sense as Tokens are issued. Defining a specific Token grant with the necessary input parameters would fit nicely.

Best regards,
Kai

From: OAuth <[e-mail]<mailto:[e-mail]>> on behalf of Dmitry Telegin <dmitryt=[e-mail]<mailto:[e-mail]>>
Date: Friday, 5. April 2024 at 00:41
To: Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>>
Cc: oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] Transaction Tokens issuance in the absence of incoming token

Hello Atul,

As an alternative to Token Exchange and separate (new) endpoint, have you ever considered OAuth 2.0 Extension Grants<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6749*section-4.5__;Iw!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthaF41vnj$>? This could give us more flexibility as will let us define our own set of input parameters and validation rules (opposite to Token Exchange that restricts us to subject_token and friends).

Regards,
Dmitry

On Thu, Apr 4, 2024 at 11:02 PM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
Thanks very much for your feedback, Joe!

On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey <[e-mail]<mailto:[e-mail]>> wrote:
Hi Atul,

I'm just starting to review the transaction tokens draft and have only a minimal understanding of the token exchange document at this point so I'm lacking a little background, but I have a few comments and questions below.

On Fri, Mar 29, 2024 at 10:39 AM Atul Tulshibagwale <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,
We had a meeting today (notes here<https://urldefense.com/v3/__https:/hackmd.io/@rpc-sec-wg/HJNXYKkk0__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthSyWxSbV$>) in which we discussed the question of what we should do if there is no incoming (external) token in the request to issue a Transaction Token<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthe6t5FmT$> (TraT). We identified a few circumstances under which this can happen:

  *   The requesting service is triggered by a non-OAuth based flow such as email or an internal trigger
  *   The client of the requesting service uses means other than an access token to authorize the call (e.g. MTLS)
[Joe] I think there will be a fair number of systems that support means of authorizing non-oauth flows.


We identified a few possibilities listed below. Please note that the Transaction Tokens draft assumes that the TraT Service trusts the requesting service, so all the possibilities below assume this.


[Joe] yes, you are trusting another part of the system to perform some authorization and inform the token service of the result.

Here are some possibilities we discussed:

  1.  Request Details: Put the subject information in the request_details parameter of the TraT request, and the subject_token value is set to "N_A"
  2.  Self-Signed Token: The requester generates a self-signed JWT that has the subject information and puts that in the subject_token value
[Joe] I like having signed tokens, but if this is really information just exchanged between two endpoints it may be more work than necessary.

  1.  Separate Separate Endpoint: The TraT service exposes a separate endpoint to issue TraTs when there is no incoming token, and that endpoint can be defined such that the request does not have a subject_token parameter. This endpoint is not a profile of OAuth Token Exchange
  2.  Separate Endpoint Only: Extending the thought above, the requester can always extract the content of the incoming token into the "request_details" parameter, so why do we need the Token Exchange endpoint
[Joe] What do we gain by using token exchange? While it seems that there is overlap between delegation/impersonation it seems that transaction tokens are sort of a superset and contain additional information about the context of the transaction.   If it looks like token exchange is too constraining then transaction tokens may just be a different use case.  With the understanding I currently have I'd either go with 4. Separate Endpoint Only or 2. Self Signed token.  Splitting the endpoints could be valid, but it seems a bit weird for me, if we did decide to do that then probably we wouldn't need to sign the information unless the request is going to traverse multiple systems.


We would like to understand how the group feels about these choices, or if you have other suggestions / thoughts on this topic.

Thanks,
Atul

--

Error! Filename not specified.<https://urldefense.com/v3/__https:/sgnl.ai/__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthWE6M_vP$>


Atul Tulshibagwale

CTO

Error! Filename not specified.<https://urldefense.com/v3/__https:/linkedin.com/in/tulshi__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthdcL8-tf$>Error! Filename not specified.<https://urldefense.com/v3/__https:/twitter.com/zirotrust__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthbfiKcf_$>Error! Filename not specified.<mailto:[e-mail]>

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthVWkx-Kq$>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthVWkx-Kq$>
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthVWkx-Kq$>

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthVWkx-Kq$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IaritBR30A-OIqtvw3r5q6_aqkOROPghBPV4SoaRKASDbORVwY8WPRHKgkC7kPF3SIu2uOfYw3rthVWkx-Kq$>
________________________________


The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.