> -----Original Message-----
> From: Mike Jones <michael.jo...@microsoft.com>
> Sent: Wednesday, October 24, 2018 5:58 PM
> To: Jim Schaad <i...@augustcellars.com>; ace@ietf.org
> Subject: RE: [Ace] WGLC for draft-ietf-ace-authz
>
> 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.
You are right it is not a coincidence. You have been asking that they match
up for quite a while and at one time the authors tried to do this. This
does not mean that it should be that way.
>
> 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.
This is something that I think is incorrect - see my mail on 10/3.
>
> 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.
If they are creating a new registry - which means not going in the CWT claim
registry then it makes sense for them to assign numbers. I agree on the
content format registration unless they have gotten an early registry done.
>
> 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).
>
> 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. 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.
>
> -- 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.
Yet another reason why we should not be combining these registries into a
single one in my opinion.
Jim
>
> -----Original Message-----
> From: Ace <ace-boun...@ietf.org> On Behalf Of Jim Schaad
> Sent: Monday, October 8, 2018 2:35 PM
> To: ace@ietf.org
> Subject: [Ace] WGLC for draft-ietf-ace-authz
>
> The chairs believe that the set of documents dealing with the OAuth
> framework for constrained environments is nearing the point that we should
> be able to advance it to the IESG for publication. We therefore want to
> have a full list of issues that need to be dealt with at the Bangkok
meeting.
>
> This starts a 2 week WGLC for draft-ietf-ace-authz
>
> We know that the following issues are outstanding:
>
> draft-ietf-ace-authz
> * There are a couple of esoteric issues around listing AS servers
associated
> with resources in a Resource Directory
>
>
> Jim & Roman
>
>
>
>
> _______________________________________________
> 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