Subject: [Ace] Nits in draft-ietf-ace-oauth-authz

From: Ludwig Seitz <[email-masked]>
Date: Wed, 11 Aug 2021 06:42:47 +0000

Hello Ace,

I'm currently dealing with some nits in draft-ietf-ace-oauth-authz that I have discovered during the final IANA check. For one of them I need group feedback: 

The draft defines a CBOR abbreviation for the Introspection parameter 'cti' which is the CWT identifier defined in RFC 8392, however it turns out that parameter was never defined as Introspection response parameter, it only exists as CWT claim.

 Can this draft just add 'cti' to the OAuth Token Introspection Response parameters without affecting the progress of the draft at this stage?

(For those interested, the other nits are: 1. Inconsistent IANA tables where some had the column "Original Specification" and some didn't for the CBOR
abbreviation mappings, 2. An obsolete reference that needed to be updated in an IANA entry).

/Ludwig

--
Ludwig Seitz
Infrastructure Security Analyst
Combitech AB
Djäknegatan 31 . SE-211 35 Malmö . Sweden
Phone: +46 102 160 846
[email-masked] . combitech.com This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above of any such misdirection Please consider the environment before printing this e-mail!

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Aug 2021 20:49:46 -0700

>  Can this draft just add 'cti' to the OAuth Token Introspection Response parameters without affecting the progress of the draft at this stage?

The relevant OAuth registry operates under the "specification required"
policy.  Since we don't currently talk about "cti" in Section 5.9.2 that
covers the other introspection response parameters (nor elsewhere that I
could find), I think this means we'd need to add a new paragraph or so of
text to describe the use of this introspection response parameter (i.e., by
analogoy to the existing "jti" introspection response parameter).  That's
enough new text that I'd want to see a specific all for comment on the WG
list to confirm consensus (probably two weeks, since we're already in the
RFC Editor queue and there is not much slack time later in the process).

I'll also float the topic with the IESG and get a better handle on whether
an IETF-wide call is needed as well (myself, I don't see a need, since the
work as a whole pretty clearly envisions that this is part of it).

Thanks for catching this, and sorry that it is not easier to resolve.

-Ben