Mike, Writing a document to do this is easy. I am not clear that there is anybody that is going to implement this. Are industries such as banking going to abandon JWT for CWT?
Jim > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Mike Jones > Sent: Tuesday, October 30, 2018 11:52 AM > To: Ludwig Seitz <ludwig.se...@ri.se>; ace@ietf.org > Subject: Re: [Ace] WGLC for draft-ietf-ace-authz > > 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 <ace-boun...@ietf.org> On Behalf Of Ludwig Seitz > Sent: Tuesday, October 30, 2018 5:13 AM > To: ace@ietf.org > 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 > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
