IT CAN'T BE A COINCIDENCE: There's clearly a relationship between many of the CBOR numeric values used in this this specification and corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is currently unspecified and the goals behind it are undefined. The spec should be augmented to make the nature and goals of this relationship explicit. I infer that there's such a relationship because the Mapping Parameters to CBOR in Section 5.6.5 apparently carefully do not overlap with the values registered in the IANA CWT Claims registry at https://www.iana.org/assignments/cwt/cwt.xhtml. The Introspection mappings in Section 5.7.4 apparently carefully use the same values as CWT for the same things, but then adds additional values. And some of these values are the same as values proposed for the CWT Claims registry in 8.13. This has to be more than a coincidence but the spec doesn't currently say why.
Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibility of them being used in signed requests in a manner analogous to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17. The parameters need to be registered to avoid future claim number conflicts. While conflicts have clearly been carefully avoided to date, they will inevitably occur in the future unless the values are actually registered. Please do so. DON'T SQUAT ON NUMERIC REGISTRY VALUES: Please change all instances of numbers to be assigned by designated experts in existing registries from specific values to "TBD". For instance, all the values for the CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD. Our chair, Jim Schaad has been a vigorous advocate of not squatting in my past interactions with him as a Designated Expert and I believe would support this request. Likewise, the "19" in the CoAP Content-Format Registration in Section 8.15 should become TBD. req_aud: Several examples use the "req_aud" parameter without defining it. Doesn't this duplicate the "resource" parameter defined by https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01? If so, please delete this parameter and use "resource". If not, say how it is different and why the differences are necessary. rs_cnf: There isn't a clear normative definition of this parameter. It's mentioned obliquely but its purpose, syntax, and semantics should be plainly stated (as with each other newly defined parameter). The proposed numbers in Figures 12 and 16 contain mismatches. For instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 in Section 5.7.4. There's too much alignment for it to be a coincidence but if you intend alignment, please say so explicitly and fix the alignment. The proposed ongoing alignment should also be described in the registration instructions for the Designated Experts. -- Mike P.S. Per my earlier reviews of this specification, in my view as a Designated Expert for the CWT Claims registry, I believe that it's not appropriate to use up rare single-byte identifiers for most of the OAuth parameter encodings specified in 5.6.5. I could be persuaded that "scope" merits one of these rare numbers, but "profile", "error", "grant_type", "access_token", and "token_type" probably do not, as they are application-specific and not of general applicability. I also believe that some of the other Designated Experts for this registry agree with me. -----Original Message----- From: Ace <[email protected]> On Behalf Of Jim Schaad Sent: Monday, October 8, 2018 2:35 PM To: [email protected] Subject: [Ace] WGLC for draft-ietf-ace-authz The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should be able to advance it to the IESG for publication. We therefore want to have a full list of issues that need to be dealt with at the Bangkok meeting. This starts a 2 week WGLC for draft-ietf-ace-authz We know that the following issues are outstanding: draft-ietf-ace-authz * There are a couple of esoteric issues around listing AS servers associated with resources in a Resource Directory Jim & Roman _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
