# Meeting on 05-03-24

## Attendees
* Atul Tulshibagwale (SGNL)
* Rifaat Shekh-Yusef (EY)
* Kelley Burgin (MITRE)
* Mike Jenkins (NSA-CCSS)
* George Fletcher (Capital One)
* Brian Campbell (Ping)

## Agenda
* Sender constraining mechanisms in ID-Chaining (turns out it's hard...)

## Notes
* Issue is binding the last client in the request
* Solution:
* New claim in the assertion, which includes "client_id" and "cnf" fields

* (George) A client_id without a trust domain is invalid.
* (Kelley) We need a way to resolve that
* (Brian) pastes https://github.com/oauth-wg/oauth-identity-chaining/issues/86#issuecomment-2077999207 into the chat as a recap of the points that need to be considered
* (George) We should separate client identification from sender constraining
* (Kelley) The lack of trust domain reference is a good reason to not include client_id in the assertion
* (George) What is the binding you are looking for?
* (Kelley) We want to bind the token to the (?)
* (George) Question, does the authz grant JWT need to include a CNF claim about client in domain A, so that wehn the grant is presented to domain B, then the authz server in domain B can validate that it was presented.
* (Brian) Assumption this is unspecified and would need to be done here. cnf claim could be used to do the binding, but nothing says how to do it in other standards. implied ony and not written down. Nopropagation of client ID, short of stuffing it in the apt claim (a dumping ground for calims people htink will be needed). Validation in what would be step C - could be TLS or DPoP, nothing that says to check on the confirmation claim. Some checks, some don't Thehones Brian knows of won't. Maybe a new grant type to convey the intent. Grant has JWT Bearer in it, also in MTLS btw. But perhaps a new grant type for Step C. Section 5 of RFC 9449. Also in Section 3 of the MTLS draft.
* (Mike) How would this work for an extra hop from a->b-c.
* (George) Turtles all the way down, start with token exhcange again and run the protocol again.
* (Mike) Thanks makes sense - maybe no changes needed.
* (Mike) If there was a C, the client ID would be A no matter what
* (Brian) Better to take out the Client ID -propagation of client identity needs to occur through exxpanding in the act claim, binding through cnf.
* (Rifaat) should we assume that?
* (Brian) I't a little weird - it is required for the information ot pass through - just tease out the pieces at each step.
* (Rifaat) This should be clearly specified that the same certificates are used. Is that valid all the time, or are there cases when it is different
* (Brian) Binding is on the hash of the cert.
* (Brian) what is PR?
* (Kelly) Protected Resource
* (Brian) Sender constraining for token exchange in Step B, somehat implicti in the standards, results in something in step C, defining step c is a new grant type.
* (George) we don't need to change token exchange, but we need to define the processing steps, describingr step B.
* (Brian) We can define it here and it will have utility elsewhere. Start doing it here, if there is a need to extract it.
* (Pieter) Would it be needed for transaction tokens
* (George) We can do this in this spec and other can use it - may not be needed for transaction tokens.
* (Kelly) Enough actionable feedback - wil make updates and then discuss next week. Will try and get it done early. Will like some feedback on next iteration.
* (Brian) just realized I said some of the step letters wrong so be aware that I messed up when reviewing the notes above. sorry...