Thanks for your responses, Ludwig. Responding to your point about "Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]." The point of the alignment was to enable signed requests to be expressed as CWTs - just as OAuth signed requests are expressed as JWTs. But given the high likelihood of numeric CWT claim collisions with unregistered OAuth request number values assigned by the spec, this won't actually work in the long term unless the request parameters are registered as CWT claims. Collision-free alignment without IANA registration is a fleeting situation. Please make the alignment permanent by registering the needed claims.
I get Jim's point that there are other ways to do signed requests. If this working group wants to define a different signed request syntax for ACE OAuth requests than CWTs, that's fine, but if so, please do so before this draft finishes. If a different signed request format is used, I'll note that there's no need for claim alignment with CWT [RFC8392] - in which case the draft should probably abandon it up front. I'll note that abandoning the current alignment is more work and would be more confusing to implementers than simply using CWTs but multiple choices are possible. The most important thing is to pick one now. Industries such as banking are REQUIRING signed requests. Since you asked about signed responses, those are also in the works for OAuth, for the same reasons - including requirements from the banking industry. See https://openid.net/specs/openid-financial-api-jarm.html. (Just as the OpenID Foundation standardized signed requests in 2014 in https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in 2014 and then an IETF version was created, signed responses are currently on a similar trajectory.) Per your question about values in IANA registries to be assigned by designated experts being TBD, the normal way of providing short-term values for interop purposes is to say "TBD (maybe <some number>). For instance, you'll see that usage at https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-7.1.1. I could live with "access_token" having a single-byte representation, since as you point out, it is needed for every ACE OAuth interaction. An "error" value is only needed when something goes wrong, so that doesn't seem like a case that needs to be optimized for space. A two-byte "error" representation will only be used when errors have occurred, so shouldn't be a problem. -- Mike -----Original Message----- From: Ace <[email protected]> On Behalf Of Ludwig Seitz Sent: Tuesday, October 30, 2018 5:13 AM To: [email protected] Subject: Re: [Ace] WGLC for draft-ietf-ace-authz On 25/10/2018 02:58, Mike Jones wrote: > 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. For example in "5.6.5 Mapping Parameters to CBOR" there is this: "Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]." I can add some text to explain that this makes it easier to manage the abbreviations in code (no need to handle complex namespace issues, when you just use one abbreviation space). Would that address the "to make the nature and goals of this relationship explicit." part of your comment? > > 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. > I have avoided doing this so far, since there was no precedent from OAuth on doing so (registering OAuth req/resp parameters as JWT claims) and I was trying to align with OAuth in that respect. For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of the classical OAuth req/resp parameters as JWT claims ("This specification requests no actions by IANA.") How is the position of the OAuth WG on this? > 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. > I get your point. Any hints on how one usually do that while still providing provisory numbers for interop tests? > 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). > This is probably heritage from the document split. Note however that the framework (draft-ietf-ace-oauth-authz) defines some of these a CWT claims, while the params draft (draft-ietf-ace-oauth-params) only defines request/response parameters (which happen to have the same name, abbreviation and semantics). I'll go over those sections and see if there are artifacts left that need to be adjusted. > 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. > Sorry for that. Errors when trying to make the alignment. > 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. "5.7.4. Mapping Introspection parameters to CBOR [...] Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]. " (so yes, we do already say so explicitly) I will add the requested instructions for Designated Experts (good catch!) > -- 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. > I would argue that the rare single-byte identifiers should be used for the parameters typically used in constrained applications. Since "error", "grant_type", "access_token", and "token_type" are all mandatory to use, they are bound to appear in constrained cases. If we made "grant_type" and "token_type" non-mandatory in ACE (as opposed to how it is in OAuth) and define defaults I'd agree to move those into the two-byte space. "profile" is arguably going to be used in less constrained scenarios where more than one profile could be supported, so I'd agree to move that to the two-byte space as well. "error" and "access_token" are used in every OAuth/ACE interaction, so I would need some really good arguments why they shouldn't have a one-byte abbreviation. Can we reach some compromise based on these observations Mike? /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51 _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
