ADs, We were wondering if we could get your take on the following that the IANA review of this document pointed out to us.
We noticed that there are two really similar IANA registries for CWT Claims and JWT Claims; however, the registries are treated a little differently: 1) The Registry Group names don’t follow the same pattern: CBOR Web Token (CWT) Claims = registry group name CBOR Web Token (CWT) Claims = registry https://www.iana.org/assignments/cwt Appears in Section 9.1 of this document JSON Web Token (JWT) = registry group JSON Web Token Claims = registry https://www.iana.org/assignments/jwt Appears in Section 9.2 of this document Should “Claims” be removed from the “CBOR Web Token (CWT) Claims” registry group name? In chatting with IANA, they were in favor of this change for consistency but also because it may sound as if other types of CWT registries would not fit there. 2) Also, the CWT registry has a column for the “JWT Claim Name”, but the JWT registry does not have a column to mention the corresponding CWT Claim Name...the template for CWTs in RFC 8392 calls for the JWT to be listed as “corresponding”, but the template in RFC 7519 for JWTs does not call for a CWT to be listed (likely because it came first): From RFC 8392: JWT Claim Name: Claim Name of the equivalent JWT claim, as registered in [IANA.JWT.Claims]. CWT claims should normally have a corresponding JWT claim. If a corresponding JWT claim would not make sense, the Designated Experts can choose to accept registrations for which the JWT Claim Name is listed as "N/A". Is this a reciprocal relationship that the JWT Claims registry should be updated to capture? If so, chatting with IANA, they pointed out that RFC 8126, Section 2.4 does give ADs latitude to approve new columns sometimes: Under some circumstances, such as with a straightforward change that is clearly needed (such as adding a "status" column), or when an earlier error needs to be corrected, the IESG may approve an update to a registry without requiring a new document. Not sure if this case would fit into that or if this would cause the need for an I-D (or is even necessary at all). We look forward to hearing your thoughts. Megan Ferguson RFC Production Center (Previous IANA-related questions sent at AUTH48 initiation appended below). > 9) <!--[rfced] We have included specific questions about the IANA text > below. In addition to responding to those questions, please > review all of the IANA-related updates carefully and let us know > if any further updates are needed. > > a) In Table 2, we note that sections within this document are > referenced but no sections are referenced in the "Media Types" > registry <https://www.iana.org/assignments/media-types/>. Should the > IANA registry be updated to match Table 2? > > b) Please clarify "Endorsers and Reference-Value providers, Relying > Parties that...". Is "Relying Parties" part of the list of items > (option A)? Or does "Relying Parties" refer to "Attesters, Verifiers, > Endorsers, and Reference-Value providers" (option B)? Note that there > are four instances. > > Original: > Attesters, Verifiers, Endorsers and Reference-Value providers, Relying > Parties that need to transfer CMW payloads over HTTP(S), CoAP(S), and > other transports. > > Perhaps A: > Attesters, Verifiers, Endorsers, Reference-Value providers, and > Relying Parties that need to transfer CMW payloads over HTTP(S), > CoAP(S), and other transports). > > or > Perhaps B: > Attesters, Verifiers, Endorsers, and Reference-Value providers. > These Relying Parties need to transfer CMW payloads over > HTTP(S), CoAP(S), and other transports). > > c) We note that the other Claim Descriptions in both the CWT and JWT > registries from Sections 9.1 and 9.2, respectively, use sentence case > (not all words have an initial capital letter. May we update to the > Claim Descriptions in those two sections to match? > > d) For Section 9.6.2 (CBOR Tags per RFC 9277), we had a few > questions/concerns: > > i) Looking at the end of the Collected CDDL in Section 6 we see: > > $cbor-tag /= tag-cm-cbor<1668547091, cbor-collection> > $cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw> > > $cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection) > $cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws) > > Which seems to match Figure 7: > > $cbor-tag /= tag-cm-cbor<1668547091, cbor-collection> > $cbor-tag /= tag-cm-cbor<1668547092, signed-cbor-cmw> > $cbor-tag /= tag-cm-data<1668547093> ; bytes(cmw+json collection) > $cbor-tag /= tag-cm-data<1668547094> ; bytes(cmw+jws) > > However, Table 4 seems to have different descriptions in the "Tag > Content" column than we were expecting based on Section 6 and Figure > 7. Please review and let us know if/how these should be made > consistent. > > | Tag Number | Tag Content | > > | 1668547091 | bytes .cbor cbor-cmw | > > | 1668547092 | bytes-wrapped json-cmw | > > | 1668547093 | bytes .cbor signed-cbor-cmw | > > | 1668547094 | bytes-wrapped signed-json-cmw | > > ii) We don't see any corresponding IANA registrations for the > information in Table 4 (nothing was mentioned in the email we received > from IANA regarding this information and we are unable to find these > values in a search of the IANA registries). Should some IANA action > be taken to allocate these numbers (perhaps at > https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml)? > > e) Please note that the RPC will communicate any nits/edits to IANA > registry text once AUTH48 completes for consistency. > > -->
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
