Hi Joe, Thanks so much for the review. Comments inline (I'm only addressing some in this email:)
On Wed, Apr 10, 2024 at 11:44 PM Joseph Salowey <j...@salowey.net> wrote: > I have reviewed the Transaction Token document. In general I think it is > a needed document and I am glad there is work in this area. I have some > questions and comments below: > > 1. Section 4 defines Trust Domain and seems to point to RFC 7519. I > couldn't find any reference to trust domain in 7519. > > 2. Why would you not include a kid claim? it seems that key rotation > should be supported. Is there harm in requiring a kid? > gff: There is no harm in supporting kid and I don't believe it's explicitly excluded. It's probably useful to add some text around key rotation and use of kid. > > 3. From the text, I don't really understand what the purp: claim is for. > gff: The goal of the claim is to allow the transaction token to "downscope" the inbound token especially when it's from an external client. For example, if the client is a mobile app with OAuth scopes for readGroupMessaging and writeGroupMessaging (encapsulated in the access_token). Then if the purpose of the transaction is to "add a user to a group chat", then that can be explicitly codified in the Transaction Token reducing the authorization scope of the token and tailoring the transaction token to the purpose of the requested transaction. I need to add more context as you are not the first to ask about it :) > > 4. One of the things I expected to see in some txn-tokens is a > username/email, but I did not see that in any examples, while there are > privacy considerations here, is there a reason why it is not included? > Would this be in the rctx: or the azd: claim? It not clear when I would use > azd or rctx for a particular data value. > gff: the subject claim can contain any value as makes sense for the Trust domain. There is also no explicit restrictions on additional claims that can be added. Note that Yaron has provided feedback on moving back to the Security Event Token definition of sub_id which allows for more clear identification of the subject value and its type. > > 5. As discussed on the list I think there may be cases where there will > not be an Oauth token to exchange. THe decision is that this is out of > scope for this document, but the case should probably be mentioned. > gff: there is a pull request (#90 in github) covering this topic. The proposed text requires a self-signed access token (potentially using RFC 9068) for the subject_token. > > 6. Is it intended that a single transaction token service endpoint can > serve more than one trust domain? (it seems like the protocol supports, but > I am not sure if it is a design goal). > gff: I would say the original intent is that there would be a single transaction token service per trust domain. Happy to discuss that and the pros and cons. > > 7. For a replacement token 7.4 it says the replacement may not change the > rctx, but does not say anything about the azd. In section 5.2 it says > that azd: remains immutable during the call chain. It seems that these two > things do not line up and the replacement token needs something to change. > Perhaps azd is not immutable? What are the asserted values that may > change referred to in 7.4.1. > gff: Great catch!! Yes, that needs to be rectified. > > 8. Section 7.5 is referring to OAUTH client authentication? Should it > refer to RFC 8705 for mTLS/SPIFFE case? > gff: so from a non-normative perspective, we can give that as an example. Feel free to propose some text. The spec is intentionally silent on what mechanism is used for client authentication. > > 9. Section 9.1 it probably should be mentioned earlier in the document > that a transaction token cannot be issued based on a refresh token. > gff: I think I agree and that's something that hasn't been discussed previously. > > Once again, thanks for your work on this document, I think it will be very > useful. > > Joe > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!NrO-8pJTwTlsHifvL_LVyK8Mazovv7wSoS6xcnmxydwMzzrRSmc5WmBTQVtt8dekiooBnG0a26CP3XJcM0XI$ > ______________________________________________________________________ The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
