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

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 <atul@sgnl.ai> 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
>
> --
>
> <https://sgnl.ai>
>
> Atul Tulshibagwale
>
> CTO
>
> <https://linkedin.com/in/tulshi> <https://twitter.com/zirotrust>
> <atul@sgnl.ai>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>