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
