# Meeting on 6/16/2023 ## Attendees Rifaat Shekh-Yusef (E&Y) Hannes Tschofenig (Arm) Pieter Kasselman (Microsoft) Justin Richer (Bespoke) Kelley Burgin (MITRE) Mike Jenkins (NSA) George Fletcher (CapitalOne) Atul Tulshibagwale (SGNL) Arndt Schwenkschuster (Microsoft) ## Agenda - Recap of the work so far: - Transaction Tokens - Identity Chaining - Discussion on embedded tokens ## Transaction Tokens Review - Current draft [link](https://sgnl-ai.github.io/transaction-tokens/) - Isn't Transaction Tokens the same as RAR - It's not, but the requester could use RAR to request a Transaction Token Justin: - This was recently discussed on the OAuth mailing list in a discussion about RAR - Transaction Tokens are about shielding the non-client facing things from the client-facing things - You can use RAR independently of this - In a client situation, the incoming token is requested using a scope, but the internal RAR list contains a long list of users who can access the token George: - How this maps to TraTs is that a RAR represents a long list of possible TraTs. Justin: - The client should not have any say in what goes into the Transaction Tokens, which is why this is interesting George: - TraTs are short-lived - Another benefit is if you're using OAuth scopes to determine what can be done in the microservices environment, we can modify the capabilities of the token after-the-fact, after the client has already initiated the request. Hannes: - One of the talks on TraTs could use symmetric crypto, but the current draft excludes it, has that question gone away? George: - Should not require asymmetric Atul: - I have not addressed this question in the current draft. Pieter: - In the context of SPIFFE, there are already asymmetric keys available, so you don't want to invent another key management system for symmetric keys Justin: - One of the things about OAuth MTLS is: The feeling is that we're making OAuth more secure by adding MTLS, but that's not true. We are just constraining the MTLS using the OAuth token. - Instead of just relying on MTLS, you are also constraining what can be done using the OAuth token Rifaat: - MTLS is only a mutual *authentication* mechanism, it shouldn't be used for authorization Pieter: - In many cases accessing one server from another is sufficient for many people George: - The access policy may require authentication as a baseline, and the policy may have other authorization bits Kelley: - Will review over the weekend and get comments George: - The TraT draft is complementary to the identity-chaining discussion Atul: - agreed. ## Identity Chaining Review Arndt: - Providing overview of the draft - ## Transaction Tokens - Atul. Very early drafts, still some changes being made - Draft follow presentation George made in Identiverse - Four ways to interact with the Transaction Token Server - First is to do token exchange with the transaction token server. TraT includes sub_id, azc (authroization context) - Second option. TraT just passes through - Third option is to create a Nested TraT which adds and signs the TraT - Fourth option go back to the TraT server in case TraT server needs to make assertion, or the workloads doesnot have access tot he verification keys. - Hannes the TraT abbreviation for transaction tokens feels unnecessary - Rifaat the nested token can be an embedded JWT. Atul - yes. - Jutin "azc" feels a lot like authorization details. - [Hannes] Is there any standardization of the content of the "azc" object? - [George] There could be some standardization such as ... say client-instance-identifier or device-instance-identifier, but not so much of the details of the transaction - [Justin] There are two halves here. There is some client attestation which is not obvious in this doc. They're being conflated in the data structure right now. The final two claims are different. - [Arndt] The last two are more claims of a nested TraT - [Atul] The thought was to give freedom to the TraT service to put whatever is required to be preserved in the call chain, not necessarily correlating with the request - [George] Whether we need nesting or not is an interesting question we should discuss - [Rifaat] We need to cap the discussion here ## Conclusion - [Rifaat] At time this time, so we will discuss embedded tokens next week. There are some docs in the OpenID Connect set of specs. We can discuss those next week - [Rifaat] JWT embedded tokens applies here to the nested claims.