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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of Ludwig Seitz
> Sent: Tuesday, October 30, 2018 5:13 AM
> To: [e-mail]
> 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?

I think that this should be lost as a requirement in the document.  I don't
think it makes it any easier to deal with things by having the abbreviations
from two different things line up to be the same.  They need to be dealt
with on their own in code anyway.

> 
> >
> > 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?

Generally this is done by assigning temp numbers from a private number space
that are then changed at the time of registration.  Additionally one can ask
for early registrations to occur.  This is done at the discretion of the
chairs.

> 
> > 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]
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace