Attendees George Fletcher (Capital One) Aaron Parecki (Okta) Arndt Schwenkshuster (Microsoft) Atul Tulshibagwale (SGNL) Agenda Notes See issue notes.

Attendees Atul (SGNL) Joe Jublinsky (MITRE) George Fletcher (Cap One) Aaron Parecki (Okta) Arndt S (Microsoft) Ken McCracken (Google) Justin Richer (Bespoke) Brian Campbell (Ping Identity) Pieter Kasselman (Microsoft)

Attendees Atul Arndt Justin Joe George Agenda Token Buckets

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...)

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)

Attendees Atul Tulshibagwale (SGNL) Kelley Burgin (MITRE) Michael Jenkins (NSA) Joe Jubinsky (MITRE) Agenda Transaction Tokens - whether to use token exchange ID-Chaining Items

Attendees Kelley Burgin Hannes Tschofenig Arndt Schwenkshuster George Fletcher Atul Tulshibagwale Agenda Transaction TokensResolving subject_token issue (#53) Security Controls on TraTs (#74)

Attendees Aaron Parecki (Okta) Mike Jenkins (NSA) Atul Tulshibagwale (SGNL) Kelley Burgin (MITRE) Brian Campbell (Ping) Pieter Kasselman (Microsoft) Ken McCracken (Google) George Fletcher (Capital One) Joe Jublinski (MITRE)

Attendees Atul Tulshibagwale (SGNL) Rifaat Shekh-Yusef (EY) Brian Campbell (Ping) Arndt Schwenkschuster (Microsoft) Naveen CM (Yahoo) Mike Jenkins (NSA) Pieter Kasselman (Microsoft) Agenda

Issue #58 There is value in allowing the requester to be able to say "I want this data to be immutable" We should not be prescriptive in that the TraT server (Atul) Should we have the field in the request be called something other than "azd"? (George) We can have a different name in the request (George) calling it azd helps it correlate to RAR, but RAR is a super open framework, so we don't have to go that route (Kelley) The TraT server should have a policy, which allows the requester to specify the values from the request details that must / should be included in the azd (George) It's possible for a requester to be rejected (we need to specify that in the spec) Issue #61

Attendees Atul Tulshibagwale (SGNL) Rifaat Shekh Yusef (EY) Arndt Schwenkschuster (Microsoft) Brian Campbell (Ping) Ken McCracken (Google) Justin Richer (Bespoke) Pieter Kasselman (Microsoft) Kelley Burgin (MITRE) George Fletcher (Capital One)

Attendees Rifaat Shekh-Yusef (EY) Arndt Schwenkschuster (Microsoft) George Fletcher (Capital One) Dr Kelley Burgin (MITRE) Atul Tulshibagwale (SGNL) Ken McCracken (Google) Justin Richer (Bespoke) Issue Tracking

sub versus sub_id (Arndt) sub_id gives good flexibility. You could still use the iss/sub format for specifying sub (Arndt) Personally I like the sub_id claim, but sub should be allowed (George) How did Shared Signals solve this? It adds a little bit of complexity (George) The parsing does get complicated (Arndt) The spec actually says we can have both and they should be in agreement. (George) What are the significant benefits of doing sub (Atul) Token compactness (Justin) Why is that important (Atul) It was important in an earlier job

Cross-domain trust is being handled separately, so this is just within a single authorization domain Number of OAuth scopes coming from the client are going to be fairly limited, because the consent has to be simple That means, the authorization domain representing the microservices is different from the authorization domain of the client (which uses coarse grained scopes) Instead of using the external OAuth token, we can create a new token for the microservices authorization domain - the Transaction Token () The authorization token can be opaque to the left and a JWT on the right (where the microservices are) () Calling the client part an authorization domain is incorrect because the client side is untrusted (Justin) With "authlete" you can create a number of services with the same account. The token used to provision services didn't have the rights to use that service, so you needed a new token / escalate the rights of the same token () Isn't token exchange the solution to this? Adding OAuth tokens internally added a whole lot of complexity E.g. token introspection

Agenda Issues: Originator and purpose need to be added How do services authenticate the Txn-Token? Identity Chaining Separate Nested Tokens Draft WIMSE Q about Transaction Tokens

Agenda Transaction Tokens issues review WIMSE charter Multi-token container Identity Chaining Transaction Tokens adoption timeline Attendees Atul Tulshibagwale (SGNL) Pieter Kasselman (Microsoft)

abstract Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to ensure that user identity and authorization context of an external programmatic request, such as an API invocation, are preserved and available to all workloads that are invoked as part of processing such a request. Txn-Tokens also enable workloads within the trusted domain to optionally immutably assert to downstream workloads that they were invoked in the call chain of the request. --- middle Introduction Modern computing architectures often use multiple independently running components called workloads. In many cases, external invocations through externally visible interfaces such as APIs result in a number of internal workloads being invoked in order to process the external invocation. These workloads often run in virtually or physically isolated networks. These networks and the workloads running within their perimeter may be compromised by attackers through software supply chain, privileged user compromise or other attacks. Workloads compromised through external attacks, malicious insiders or software errors can cause any or all of the following unauthorized actions: Invocations of workloads in the network without any external invocation being present

Attendees: Rifaat Pieter George Kelley Justin Atul Agenda SPIFEE in the IETF (Justin)

Attendees Agenda Workload identities in leaf transaction tokensGeorge - need a way for intermediary servers to add extra authoritative information. Justin's solution may help with this. Justin - can we get away from putting everything in a single token. Justin - we may have a type of graph instead. Justin - we have a dictionary instead of a monolithic token. Atul - this allows a token to send multiple tokens and then reference them. Can this work with JWT embedded tokens? Justin - nothing is specific to JWT. Atul - have a draft that can be referenced by embedded JWT spec.

Rifaat reviewing updates to embedded JWT. 2. Justin - SD-JWT compatibility with embedded JWTs may need very precise processing 3. Justin - When including by reference, token does not need to be a JWT. 4. Rifaat - need to understand more about how SD-JWT changes the embedded JWT proposal. Will clarify. 5. Justin - Some early ideas on what data structure may look like. Rifaat - may just define different headers (same as DPoP). Justin - a different structure that is more a map than a list. Start by embedding a token by refernece. There may be a macro structure for carying multiple JWTs. Justin proposing to write-up a concept for this group. 6. Arndt - important aspect is that there is broad use (header and token bloat are problematic). Atul - Updated Transaction Token Draft to include JWT embedded tokens: https://hackmd.io/@rpc-sec-wg/transaction-tokens-draft Rifaat - ask participants to promote the IAB Identiy Program that was recently announced: https://github.com/intarchboard/proposed-program-whodis/blob/main/README.mdNo specific meeting, but there will be discussion in the open hours. Token Chaining