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
