> -----Original Message-----
> From: Ludwig Seitz <[email protected]>
> Sent: Tuesday, February 26, 2019 4:32 AM
> To: Jim Schaad <[email protected]>; draft-ietf-ace-oauth-
> [email protected]
> Cc: 'ace' <[email protected]>
> Subject: Re: draft-ietf-ace-oauth-authz
>
> On 25/02/2019 18:08, Jim Schaad wrote:
>
> >>> 3. In section 8.3 - Is/Should there be a requirement that the
> >>> error also be registered in an OAuth registry? If so then this
> >>> needs to be part of the expert reviewer instructions on this
> >>> registry.
> >>
> >> The expert reviewer instructions already state this:
> >>
> >> "Since a high degree of overlap is expected between these
> >> registries and the contents of the OAuth parameters registries,
> >> experts should require new registrations to maintain a reasonable
> >> level of alignment with parameters from OAuth that have comparable
> >> functionality."
> >>
> >> This includes the error registry, do you think this is
> >> sufficiently clear or should I elaborate?
> >
> > The question I had was the difference between SHOULD and MUST be
> > registered. The text there says - try and keep them in sync, but if
> > they are not it is not a problem. If that is what you want then
> > this is not a problem, I was just validating this.
>
> The intention of the "should require ... a reasonable level of
> alignment" was "try and keep them in sync, but if they are not you need
> a good reason for this".
>
> Your alternate interpretation makes me think the text is not worded
> strongly enough.
I think that this is basically the same thing. The only thing that you might
want to add is some guidance on what constitutes a good reason.
>
> >
> >>
> >>>
> >>> 4. In section 8.4 - Is there a reason to require a specification
> >>> for this registry? Should it be sufficient to have somebody
> >>> request that a mapping be registered and the DE approves it? The
> >>> previous comment would apply
> >> to
> >>> all of the mapping registries that are just mappings.
> >>>
> >> The idea is to prevent the squatting of low byte count
> >> abbreviations by parameters that are not frequently used, thus
> >> there is a range of different policies for different integer
> >> abbreviation number ranges. (note: I'm following the example of the
> >> CWT specification here)
> >
> > Not requiring a document to exists could still allow this. IANA
> > would still have the DE approve the assignment.
> >
>
> Ok so you mean not having "specification required" for -65536 to -257
> and 256 to 65535 and not having "standards action" for -256 to 255 would
> be ok?
>
> Note that this would be different from the policy in RFC 8392 (CWT).
Yes I understand that this is different from CWT. When looking at the
registries you basically would write a specification which contains the
following text:
If, for example , in section 8.4 it was already registered in the OAuth
registry, then the document would boil down to:
Please assign a number in the "OAuth Grant Type CBOR Mappings" registry with
the following properties:
Name: grant_type_name
CBOR Value: TBD
Reference: [This document]
Original Specification: [The document for grant_type_name] in the "OAuth Grant
Type" registry.
This seems like it is really overkill to have to produce a full specification
with of one page when an email to IANA would seem to have the same info. If
you were defining a new grant type, then a full spec would be useful but it
would also be expected to do the registration in the "OAuth Grant Type"
registry as well as in this registry.
I am not overly worried about getting this resolved at this point as it can be
changed later if that makes more sense.
Jim
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
