Re: [OAUTH-WG] Transaction tokens draft-ietf-oauth-transaction-tokens-01 - my comments

[Atul Tulshibagwale <[e-mail]>]

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 [e-mail] <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>