MEeting on 2023-12-08

# Meeting on 2023-12-08 ## 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) ## Schedule * Skip for the rest of the year * New meeting invites for the new year ## Agenda * Brian's feedback on Transaction Tokens * (Arndt) GitHub Updte ## GitHub Update * Both repos (Transaction Tokens and Identity Chaining) moved to OAuth * Workflows updated so that any release tagged in GitHub will result in a new datatracker upload ## Brian's feedback * Review mainly from a Token Exchange perspective * Thinking from a product point of view too * Transaction Token draft doesn't use the Token Exchange spec properly * (Pieter) Can you share the details possibly offline * (Brian) Grant type is needed on the request * (Brian) Some response required fields are missing * (Brian) "Expires in" should be added * (Brian) The use of "token_type" and "issued_token_type" is confusing * (Brian) examples are also not aligned with the rest of the draft * (George) Super helpful. I can take a pass to make it more compliant * (Brian) Most concerns are just with the syntactic compliance, at the surface level * (Brian) Some misalignment with the Token Exchange spec: You have the opportunity / baggage to consider that OAuth client auth already exists at this endpoint, by nature of it being an OAuth token endpoint. The endpoint may not understand Spiffe * (Justin) Since we are using Token Exchange, it inherits the properties of a normal token endpoint * (Brian) Token Exchange allows for use without client authentication. There just needs to be better treatment / alignment of the two * (George) We profiled Token Exchange, because there's a lot of overlap. Perhaps we should just define a new endpoint, so that it doesn't carry the baggage * (Brian) That's an option, but perhaps not worth separating it that much. There's a potential for functionality like this to be plugged into existing products. * (George) We don't want to require or preclude Spiffe, so how do we structure it so that we allow for using existing client auth mechanism or you could use Spiffe * (George) There's an issue from Just in the repo, about whether the token should live outside the trust domain? * (Justin) The spec has two parts - token formats and token issuance * (Justin) We could have those as two different docs * (Atul) A format spec without a way to issue them may not be very useful * (Brian) The transaction tokens are tightly bound to an invocation from the external world * (Justin) There may be other ways of minting Transaction Tokens without using Token Exchange * (Brian) The external service could issue it itself? Some more clarity that these are two distinct parts will be useful, but splitting documents may not be a good idea. * (Pieter) Clarifying that it is separable is good, but for implementers to be able to get one document that covers one way of issuing Txn-tokens is good * (Atul) The action item here is: Clarify format to be different from the issuance mechanism. * (Pieter) Another action item: We should clarify that the existing client-auth mechanisms to authenticate the requesting service to the Txn-token server is needed, but it should also say that other mechanisms are also possible * (Atul) (e.g. Spiffe) * It seems that how Transaction Tokens are conveyed is missing, but it should be discussed * (Atul) There is an existing issue and some prior discussion on this (I think) * (Pieter) We don't want to preclue any mechanism, but we should have some guidance on how to convey Txn-Tokens in the draft * (George) There's an existing issue, and feedback from Yahoo, having a separate header would be super valuable. Even if you wanted to use client-auth as your authentication mechanism, having this as a separate header is useful * (Atul) I think [this](https://github.com/oauth-wg/oauth-transaction-tokens/issues/21) is the issue * The draft is very specific and prescriptive in some places, and open ended and unspecified in some places * E.g. the token has a very detailed description, but no way to convey the tokens * A few more nitpicky points: * Section 2.2.1, we should not encourage use of ID Tokens in this draft because there are other problems with it. OIDC should be used for transferrence of identity, but not for API authorization * (Pieter) In that pattern, do you see use cases where the relying party had an ID Token and wants to exchange it for something else? * (Brian) In general I would envision some kind of exchange to get an OAuth token before we get to the API gatweay * (Justin) One issue I have discussed with Evan Gilman is the misuse of ID Tokens. We definitely do not want to encourage that, but also we may want to specifically discourage that. One principle of JWT access tokens doc was to make access tokens look different from ID tokens. * (George) * (Brian) We should just remove the "or an ID Token" language from the draft, so that we do not legitimize that pattern * (George) Brian is recommending that we should be silent about it, and address that issue elsewhere if needed * (Brian) The sentence should just say "such as an OAuth Token" (and drop the ID Token part) * (Rifaat) Why not preclude it? * (Brian) Because it is well beyond ths scope of what this document is about * In the "Benefits of Transaction Tokens" there is residual language from nesting. * (Atul, Pieter) Yes, it's leftover text, we should remove * In the format section, "headers" are confused with "claims". It is important to fix it. * On the "typ" header in JWS or JWT, it is defined to be a media type, so we need to fit within the framework of what is provided by the lower layer, so a possible acceptable value is "application/..." You can look at how DPoP or JWT Access Token profile does it as a template of how it is done * Re: Claims: * Issuer can be implied and excluded * (Pieter) we should discuss this later * "sub" would be preferable to "sub_id" here, because the expressiveness of "sub_id" may not be required here * Sender Constraining these things can bring a world of pain, that the text in the draft doesn't convey * It should either not be said or some additional guidance should be incorporated * E.g. If you sender constrain them to one caller, then it cannot flow through a call chain because it is bound to one caller * (Pieter) * (Justin) Two points: * It is important to note that sender constraining is useful only if enforced. * Sender constraining doesn't strictly mean single sender. This is something that Spiffe can help with * (Atul) We should remove the "sender constraining" language * (George) Originally Txn-tokens were always intended to be bearer tokens. So we could just be silent on it, or we could say "if you have a sender constraint use case, Txn-Tokens may not be the right solution" * (Justin) Fundamentally sender constrianing is an orthogonal problem * (Justin) The part of the document that is about the semantics of the model. * (George) We should just be silent about sender constraining, and not try to solve the problem * (Justin) There could be an "implementer's notes" kind of discussion. * (Pieter) We should either describe it more, or have it in another document. ## Brian's raw notes in prep for this call: https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html Perspective esp informed by RFC 8693 Token Exchange and product support thereof Notes from before 118: “it's better but still seems problematic. Confusing - maybe just me but ... Claims under defined. Auth w/ token exchange should be client auth. Extra param on TE request is hard for (some) existing impls. The Txn-Token Request isn't valid per Token Exchange [RFC8693]. Response also not valid. IANA needs lots of help.” High level points: Token Exchange compliance Authentication layer (for lack of a better word) How Txn-Tokens are conveyed seems needed General sense that it’s both very specific and under defined Some specific points: https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#section-2.2.1 Should not encourage ID tokens in this context - “or an OpenID Connect [OpenIdConnect] ID token” https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-benefits-of-txn-tokens This doesn’t seem true (residual from nesting?) - “Through the presence of additional signatures on the Txn-Token, a workload receiving an invocation can also independently verify that specific workloads were within the path of the call before it was invoked.” https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-jwt-header Headers are not claims. Typ header is a media type + all that entails https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-required-claims Iss could be implied Sub_id as just sub and claims in general feel both very specific and under defined https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-requesting-txn-tokens Don’t love the extra required parameter but getting used to it Request / response are not quite RFC8693 compliant (some of which will be awkward and I’m sorry about that…) and/or don’t match w/ examples grant_type needed access_token issued_token_type token_type are required (and the types are funky) No reason to prohibit expires_in https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-mutual-authentication-of-th Awkward WRT oauth client auth https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-sender-constrained-tokens But brings so much more in complications that aren’t apparent/discussed… https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-00.html#name-iana-considerations Registration requests are off or missing or ….