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 <a...@sgnl.ai> wrote: > Thanks very much for your feedback, Joe! > > On Wed, Apr 3, 2024 at 10:16 AM Joseph Salowey <j...@salowey.net> 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 <a...@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> >>> <a...@sgnl.ai> >>> _______________________________________________ >>> 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
