On 24/02/2019 01:13, Jim Schaad wrote:
1. Figure 4 needs to be updated as it no longer matches Figure 3.
Fixed
Fixed, I made that "token error response" as one of the specified locations in RFC 6749 11.4.1.2. In section 8.2 - Should he error usage location match any of the current values in the table. Possibly "authorization server response"
(side note: The OpenID and Kantara IANA registrations apparently missed the limited range of values specified for this field and used custom location descriptions).
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 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.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.
(note: I'm following the example of the CWT specification here)
5. In section 8.5 - You are missing two fields of the registration template. Specifically should the expiration time field be noted in the "Additional Token Endpoint Response Parameters" column.
Fixed
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
