> -----Original Message-----
> From: Ludwig Seitz <[email protected]>
> Sent: Monday, February 25, 2019 6:21 AM
> To: Jim Schaad <[email protected]>; draft-ietf-ace-oauth-
> [email protected]
> Cc: 'ace' <[email protected]>
> Subject: Re: draft-ietf-ace-oauth-authz
>
> On 24/02/2019 01:13, 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.
>
> >
> > 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.
> >
> > 6. In section 8.9 - see comments of section 8.3 and 8.4
> >
> > 7. In section 8.11 - see comments of section 8.3 and 8.4
> >
> See above
>
>
> > 8. This document has an IPR disclosure on it. If anybody has any problems
> > with the current disclosure then they need to speak up now.
>
> Processing ...
>
> The changes are currently only in the github version, I will upload a
> new version of the draft soon.
>
> /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
