Re: [Ace] WGLC for draft-ietf-ace-authz

[Ludwig Seitz <[e-mail]>]

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 [phone]