OAuth Virtual Interim Meeting on Transaction Tokens & Identity Chaining

• Date: 16th December 2024

• Minute Taker: Hannes Tschofenig

• Relevant documents: draft-ietf-oauth-transaction-tokens-03 and
  draft-ietf-oauth-identity-chaining-02

Rifaat provided an introduction and bashed the agenda.

Identity Chaining

Pieter started his presentation and started with an overview of the
topic. Then, he continued with the discussion topic for today:
sender-constrained access tokens

Brian mentioned that the discussions on this document continued after
the last IETF meeting. Hence, there is some context that is not
available to all participants.

Hannes asked whether both use cases presented need to be addressed.

Pieter and Kelley believe so.

Kelly continues his presentation discussing the reasons why the two use
cases are needed. The core argument is that the resource server may not
be able to access the authorization server of the second domain. This
then requires the client to go through a proxy with the help of a
delegated sender constraining of tokens.

Kelly talked about more details of use case 2 (where the proxy) is used.

Kelly asked whether the interaction between the authorization servers
needs to be specified.

Hannes believes it has to be described in the draft due to their
inter-domain nature.

Pieter asked Kelly for similiar applications that use this pattern.
Pieter then goes on to talk about these applications based on the
slides, and uses the term "platform proxy" for the proxies between
authorization servers/identity provider and workloads (example is a
variant of Istio).

He listed a number of questions for the working group on slide#19.

Pieter asked Hannes for feedback. Hannes has to think more about the
questions and encourages the rest of the group todo so too.

Transaction Tokens

George starts the presentation.

The promise is that the transaction token offers security for requests
across multiple service invovations.

Hannes asked whether there would be a benefit of using RAR.

A different claim name (instead of azd the tctx claim is used).

George recommends reading issue#111 on batch processing. Example is:
user request account deletion, which requires data to be deleted in a
number of places. The longer it takes for the transaction to complete,
the more information in the context has to change.

George says that there would be a benefit when the external system
already provide RAR-based information. In that case the content could
potentially just be copied.

Hannes asked for the implication of supporting the functionality? For
example, fetching multiple transaction tokens at once, being able to
request new transaction tokens again and again.

Rifaat: Brian, Arndt, Pieter argue that this should be out of scope for
now.

Hannes is wondering whether this is not a core feature. Is it too
difficult to get this information?

Brian: There is a mechanism for obtaining the token and the transaction
token itself. Brian believes that batch processing is complex.