# Meeting on 2024-04-26

## Attendees
* Rifaat Shekh-Yusef
* Pieter Kasselman
* Kelley Burgin
* Brian Campbell
* Atul Tulshibagwale

## Agenda
* Self-signed JWT issues in Transaction Tokens
* Token binding in ID-Chaining (Sender Constraining)

## Notes
* (Atul) Using self-signed tokens has issues, so can we use just a JSON-object
* (Brian) Signing JWTs: The basic blocking and tackling issues need to be taken care
* (Pieter) We need the structure that JWT provides
* (Brian) JSON can be structured, and is easy to build for (lots of libraries)
* (Pieter) If you are working in this space, you are already using JWTs, so using JWTs seems natural
* (Pieter) If we don't do that we end up defining a custom structure, so why not use JWTs
* (Pieter) You could specify the required claims and you could sign it if you wanted to
* (Pieter) We've seen implementers elevate trust on tokens just because it has a signature, without verifying the signature. That is an implementation choice. Having self-signed could be valuable if there is trust in the signing key.
* (Atul) Open issues with curent PRs:
* `exp` value of self-signed JWT in request
* IANA section work: Use "claims" and "fields" isn't correct (both in this section and elsewhere in the draft)
* Use of "typ" header as txn_token isn't right.
* The URN `urn:ieft:params:oauth:token-type:txn-token` is missing a registration
* Txn-Token Request section has formatting issues
* (Atul) Based on this, many of the issues are with the draft and PRs irrespective of the use of self-signed JWTs, so we should continue to use that.

### Sender Constrained Tokens
* (Kelly) started an e-mail thread. Kelly i looking into MTLS first. Have been thinking about it for a few years. Best idea is an additional claim to communicate the cnf claim. Interested in other options
* (Pieter) Why MTLS?
* (Kelly) Environment they are deploying in has PKI and certs, so this makes it easy to use MTLS?
* (Pieter) What about the break and inspect proxy problem.
* (Brian) Issue is with TLS terminating before it gets to the application.
* (Kelly) Need to think about whether this is an issue.
* (Pieter) Break and inspect beahviour is a potential exfiltration point for tokens.
* (Kelly) Concerns over AS as client behaviour. Any options for MTLS and DPoP in this case.
* (Brian) Not a lot of difference between these two, but is tied to a specific request. e-mail was an attempt to enumerate. For AS as a client, it will have to passthrough/proxy the cnf claim.
* (Kelly) Need to invent a new claim.
* (Mike) May vary based on whether it is business to business or end point to a service. B2B may not make a difference, but endpoint to a user there is a use case to validate the client as a requirement.
* (Pieter) Would it make sense to also pass the proof around?
* (Kelly) Depends on the amount of proof we put in the AS.
* (Brian) How would that work?
* (Pieter) Perhaps just make it the responsibility of the AS to validate the key and pass the cnf claim
* (Brian) Passing the proof could work with application layer, but lots of extra work. Very hard to do with MTLS. Need high evels of trust in these cases.
* (Kelley) I'm happy to capture this discussion in a text (in the draft?)
* (Brian) It's more important to capture the sender-constraining in the case where the AS isn't the client. I'm not entirely sure it is worth getting into. I don't think that can be the only case where sender constraining is specified
* (Kelley) I can take a stab at that next week and get something out for review