Hi Yaron, Thank you so much for this feedback. I've created issues <https://github.com/oauth-wg/oauth-transaction-tokens/issues> for many of the items in your email, and a PR <https://github.com/oauth-wg/oauth-transaction-tokens/pull/85> for the minor text fixes you identified.
Atul On Sun, Mar 24, 2024 at 8:23 PM yaronf.i...@gmail.com <yaronf.i...@gmail.com> wrote: > I had a long flight and I’m still not there yet… But had time to review > this draft. > > > > Thanks authors, this is important and useful work. It’s also quite early, > so I have a long list of comments below. > > - Intro: for "workloads", I suggest to add a reference to the WinSE > Architecture draft. > - 2.1: "the execution of a call" - I think most people prefer "call > chain" for this, where "call" only refers to a single hop. (Granted this is > more of a call tree rather than a call chain, but we use “call chain” > anyway.) > - 2.4: additional signatures: I think this is a leftover from a > previous version of the draft, and as far as I can tell it is not supported > by this version. Suggest to remove it. > - 2.5.1: typo, "in an a multi-workload". > - Figures: what is a "µ-service" and why do we need Greek letters? > - 4: the terminology section is not a good place for normative > language, specifically around the "aud" claim. > - 5.2: I think txn should be OPTIONAL. While it is very useful, there > may be architectural reasons why transaction ID issuance in an organization > is independent of transaction tokens. > - 5.2: "purp" - need a lot more discussion of this claim, also it may > be OPTIONAL too. Also, why not call it "scope" if that's what it is? > - 5.2: how is "azd" different from "rctx"? There's a whole section > about "rctx" and nothing about "azd". > - 5.2: extensibility: please say explicitly that arbitrary claims may > be added to the "azd" (and "rctx"?) objects. There is no IANA registry for > either. Note that having 3 predefined attributes complicates the situation > a bit - what happens if we want a 4th one? Also mention that any additional > attributes are local to the trust domain. > - 5.2: "sub" should be better clarified, this is not your typical > “sub”. Also, I strongly prefer "sub_id" here (RFC 9493), as the use case I > have an mind is of the subject as a human. In addition, "as defined by the > aud trust domain" is confusing, I think you want to say that "sub" is > relative to the scope of the trust domain. > - 7.1: the bullets are formatted incorrectly (see HTML version of the > draft). > - 7.4.1: maybe say explicitly "MUST NOT change the "sub"', because in > many use cases this is the most important/sensitive claim. > - 7.5: unfortunately SPIFFE is only secure for this when used in > conjunction with MTLS, so please reword the sentence (or wait for WimSE to > solve this problem). > - 7.5: SPIFFE - all caps. > - 8.1: and obviously we need an IANA section to define this HTML > header. > - 10.1: *salted* SHA256. > - 10.1: also, in most cases txn tokens MUST NOT be logged because they > contain PII (e.g. a subject that's an email address). > - 11.1: I think there is some confusion here. It is possibly useful to > define this value (if we want to embed txn tokens within access tokens). > But the "typ" header is a whole different thing, it needs to be a media > type. See > https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing > > Thanks, > > Yaron > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
