# Meeting on 04-05-24

## Attendees
- Atul Tulshibagwale (SGNL)
- Kelley Burgin (MITRE)
- Michael Jenkins (NSA)
- Joe Jubinsky (MITRE)

## Agenda
* Transaction Tokens - whether to use token exchange
* ID-Chaining Items

## Notes
* (Atul) Checking if Pieter (or others) think that the non-token based initiation of TraT Request is a legitimate use case?
* (Pieter) I'm concerned about that. The TraT is just a down-scoping of that token. Now you are essentially becoming an AS, with no prior policy applied
* (Pieter) On the list there was a suggestion for an extension grant
* (Pieter) I also remember when we were discussing VC issuance, they went through a similar process of issuing VCs, they always relied on the access token to issue the VC
* (Pieter) I'd be inclined to say have the email server obtain the access token (in the email scenario)
* (Pieter) If we feel that the token-exchange use case is not appropriate, then it might be a different draft. I feel uncomfortable about the security implications, or the assumptions we might be violating
* (George) We might be processing billions of emails a day, most of which are going to be dropped. Doing 2 calls will kill performance
* (George) Having a "TraT grant" extension to OAuth would be a single call. But my point is, what is the complexity of having two ASs in the same trust domain, one for issuing TraTs, and the other for issuing other tokens
* (George) I have had less security concerns around this. We already required the TraT service authenticates the requesting service. You can easily limit which services can effectively mint tokens. In that context, we could have the mail client send a self-signed token (a new subject token type that represents inbound mail). Similarly there may be other token type that represents "batch delete of users", etc.
* (Atul) It's possible for clients to initiate API calls without using access tokens
* (George) MTLS could represent a user, but is not very common. In that scenario, if that user asks for a TraT, and the TraT service has to understand the MTLS infrastructure, and recognize when it issues the TraT, the subject needs to identify the requesting workload and the user. So we have a lot more work to do in the MTLS use case
* (Pieter) If someone already has a token (ID Token, Access Token), that is indication that an authentication has taken place
* (George) If you collapse requester authentication and the user authentication in a single MTLS thing, then how do we distinguish the workload identity. E.g. you have CrowdStrike on my endpoint, and the endpoint has a cert on it. Something on the service has to get the CrowdStrike information (posture) and the client cert. So the API gateway needs to parse the inbound cert and pass it on to the TraT service
* (Joe) It sounds like the gateway is just a broker
* (George) For me the value of the TraT is to bind into a single entity all key aspects of a Transaction. This typically includes the subject and context (request and additional authorization details). TraTs ensure that each workload cannot modify that value
* (Joe) Everything is stateless in this regard, but something is a global broker that provides centralized capability. My worry is that there is no way to throttle or manage these transactions - everything is autonomous
* (Joe) It is contradictory to other systems that are mesh type, where there are central brokers
* (George) There is a central entity that issues the Transaction Tokens, and can apply policy to it. Logically, there is centralization at the time of issuing the TraT.
* (George) Today, the majority of deployments do nothing with transactions - it's just a random series of API calls that accomplish the task. We're just trying to add rigor to it. While the TraT based system is stateless to some extent, the resulting data gives you state.
* (Pieter) In the absence of mechanisms like TraT, people just pass access tokens around
* (George) The access tokens typically much more capable and long lived than what is required
* (George) If the access token is opaque, then the token validation endpoint needs to be hit by every user of the token
* (Pieter) Thinking about George's older comment that there will be two calls for each email, where almost 80% will be dropped. Why not issue the TraT only for the required emails
* (George) The spam workload is a part of the infrastrucutre that uses TraTs
* (Pieter) If the TraT service can distinguish between requests that have access tokens versus not have access tokens, and react accordingly. As long as it can say this is a self-signed assertion, it limits the type of TraTs it issues
* (Pieter) If we bifurcate, it bothers me
* (Pieter) I'd say we have single interface, where we use self-signed assertions in the absence of inbound tokens.
* (Pieter) we should also look at Tobias' attestation thing <ref?>
* (George) Let's say it was MTLS between the email service and the TraT service, the TraT service would be able to validate the email service, and generate a TraT based on a self-signed token generated by the email service. The TraT service looks up a table and figures out what kind of TraT it can issue to the email service. If the request fits the parameters it issues the token, otherwise give an error
* (Atul) It sounds like a self-signed token / assertion from the requester is a reasonable way forward
* (George) We kind of have that today, but we haven't specified it.
* (George) So we could make that more specific re: inbound / self-issued token
* (George) What we don't have a good solution for, is an internal MTLS scenario, where the cert identifies a human or an instance of the device
* (Pieter) where are the gaps in that scenario?
* (George) If the service were to construct a self-signed token, then we would be OK.
* (George) For calls that originate externally and have an access token, you use that, but for internally originated calls, the requester generates their own token in the TraT request.
* (Atul) I'll write it up in the next week if I get time, if not, George can write it up in the week of IIW

### ID Chaining
* (Kelley) I'll work on the sender constraining mechanism in the coming days
*