Roman Danyliw has entered the following ballot position for draft-ietf-oauth-status-list-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** For the OAUTH WG Chairs and responsible AD: this document appears to be describing new mechanisms for CWT and ISO mdoc; and a new sub-registry for CWT. I could use help understanding how this fits into the defined scope in OAUTH WG charter given that the status-list work isn’t explicitly named and CWT and mdoc aren’t directly tied to “increasing interoperability of OAuth deployments and to improve security [in OAuth deployments].” ** Section 6.3.2 ISO mdoc [ISO.mdoc] may utilize the Status List mechanism by introducing the status parameter in the Mobile Security Object (MSO) as specified in Section 9.1.2 of [ISO.mdoc]. The status parameter contains the Status CBOR structure as described in Section 6.3. It is RECOMMENDED to use status for the label of the field that contains the Status CBOR structure. Interpretting and implementing this text seems to require understanding the [ISO.mdoc] specification. Please make this a normative reference. ** Section 11.5 Reasonable values for both claims highly depend on the use-case requirements and clients SHOULD be configured with lower/upper bounds for these values that fit their respective use-cases. What is the interoperable way to access the “lower/upper bound … that fit their respective use-cases”. Perhaps s/SHOULD/should/ ** Section 11.6 Implementers SHOULD only use MACs to secure the integrity of Status List Tokens if they fully understand the risks of MACs when compared to digital signatures and especially the requirements of their use-case scenarios. What is the interoperable way to assess if an implementor “fully understand[s] the risks of MACs”? Perhaps s/SHOULD/should/ ** Sections 14.2, 14.4, and 14.5 establish new registries with a Specification-Required allocation policy. This policy includes a review/approval by a Designated Expert (DE). The current text is clear on where and when to send such requests, but it doesn’t provide any guidance to the DE on deciding how to process it. Could this please be added. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Andy Newton and Mike Bishop’s DISCUSS positions. ** Section 1.2 Modern approaches use accumulator-based revocation registries and Zero- Knowledge-Proofs to accommodate for this privacy gap, but face scalability issues again. -- Consider how this text might age in a long-lived document. -- Consider if “modern approaches” is the right characterization (if so, what does this mean?). Are these schemes (e.g., accumulator-based schemes) widely deployed? ** Section 1.3 * the specification shall favor a simple and easy-to-understand concept … * the specification shall be optimized to support the most common use cases and avoid unnecessary complexity of corner cases -- How is “easy-to-understand” being judged? -- What are these use cases? -- Consider if this text is needed ** Section 11.2 A Status List Token in the JWT format SHOULD follow the security considerations of [RFC7519] and the best current practices of [RFC8725]. A Status List Token in the CWT format SHOULD follow the security considerations of [RFC8392]. Is there any further guidance that can be given on when it is appropriate to ignore these security considerations or best practices? _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
