Hi Ken, My apologies on the slow feedback. Comments inline...
On Fri, Dec 1, 2023 at 12:16 PM Ken McCracken <kenmccracken= [email protected]> wrote: > Hi, > > Thanks for the introduction in previous WG calls. I am interested in > providing Workload call chains in OAuth tokens, and based on > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-00 > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-00__;!!FrPt2g6CO4Wadw!IpEF7S3cfiMLLcMgo_pil_Z-ByInTtOwKlarEKZSo5FUFKBkEchL6mWXvTBGRAJMILrWtY2df57q5O05Z3wF6bjb9NKJLaQGvEUaWJY$> > I have a few questions/feedback about specifics of the draft. > > 1. Section 5.2.1. Why not use the “act” claim of RFC 8693, rather than > introduce the new “sub_id” claim? > This is an interesting perspective. Are you suggesting that the transaction token would not have a 'sub' claim at all and instead have the 'act' claim? The general thinking for transaction tokens is that the subject of the transaction token should be the identity of the entity the transaction is about. I'm not sure the `act` claim captures that concept. Your thoughts? > 2. Section 5.2.1. Should the workload call chain, identifying each > workload that has requested a new txn_token, be preserved in the txn_token > claims-set, similar to the “act” claim of RFC 8693? It may be that > workloads deeper in the chain have no way to reason about prior actors, but > maybe the spec should allow for the request call chain to optionally be > preserved, in case upstream workloads can reason about downstream workloads. > For call chain "tracing" we are currently leaving that "out of scope" for the specification as there may be many ways to provide that "pathing" without having to re-request a new transaction token or wrap the original one with another signature. > 3. Section 7.2: In the text, it says “The token_type value MUST be set to > txn_token", but I think it should say “The issued_token_type value MUST be > set to urn:ietf:params:oauth:token-type:txn_token” > Yes, good catch. I'll update the spec. I was working on that section this week :) > 4. Section 7.2: I understand why you wouldn't want a refresh_token in the > response. Why can’t the response include expires_in or scope? > The issued transaction token has an `exp` and well as `purpose` claim that cover both expires_in and scope. It felt redundant to put the same values in both places. Do you see value in duplicating the values? Thanks, George > > Regards, > -Ken McCracken > > _______________________________________________ > OAuth mailing list > [email protected] > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!IpEF7S3cfiMLLcMgo_pil_Z-ByInTtOwKlarEKZSo5FUFKBkEchL6mWXvTBGRAJMILrWtY2df57q5O05Z3wF6bjb9NKJLaQGHi8umQ8$ > ______________________________________________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
