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

[Atul Tulshibagwale <[e-mail]>]

Thanks all, for your input. We discussed alternatives on a call last week
<https://hackmd.io/@rpc-sec-wg/BkdOgipkA>, 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]>
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]> 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]> on behalf of Dmitry Telegin
>> <dmitryt=[e-mail]>
>> *Date: *Friday, 5. April 2024 at 00:41
>> *To: *Atul Tulshibagwale <[e-mail]>
>> *Cc: *oauth <[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://datatracker.ietf.org/doc/html/rfc6749#section-4.5>? 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]> wrote:
>>
>> Thanks very much for your feedback, Joe!
>>
>>
>>
>> On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey <[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]> wrote:
>>
>> Hi all,
>>
>> We had a meeting today (notes here
>> <https://hackmd.io/@rpc-sec-wg/HJNXYKkk0>) 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://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/>
>> (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
>>
>>
>>
>> --
>>
>> [image: Image removed by sender.] <https://sgnl.ai/>
>>
>> Atul Tulshibagwale
>>
>> CTO
>>
>> [image: Image removed by sender.] <https://linkedin.com/in/tulshi>[image:
>> Image removed by sender.] <https://twitter.com/zirotrust>[image: Image
>> removed by sender.] <[e-mail]>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *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.*