Roman Danyliw has entered the following ballot position for draft-ietf-oauth-cross-device-security-14: 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-cross-device-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- There are diverse use cases to satisfy with the guidance provided in this document. In my assessment, additional consideration is needed to balance the listing the considerations and prescribing them in Section 2. More specifically: ** Section 2. 1. Implementers MUST perform a risk assessment before implementing cross-device flows, weighing the risks from Cross-Device Consent Phishing and Cross-Device Session Phishing attacks against benefits for users. Unless there is a defined process for performing a risk assessment, it seems to me to have little value to normatively require this step. Without a defined process, nearly everything done by an implementer would be conformant. To exaggerate a bit, would “just thinking about the risk for a fleeting second” not qualify as an assessment? ** Section 2. 4. Implementers MUST implement practical mitigations as listed in Section 6.1 that are appropriate for the use case, architecture, and selected protocols. With all of the helpful guidance in 6.1, how does an implementer know which they MUST implement based on the use case/architecture/selected protocol. Is there a deterministic (interoperable) list to arrive at what is mandatory? ** Section 2 5. Implementers SHOULD implement proximity checks as defined in Section 6.1.1 if possible. Doesn’t this bullet #5 conflict with bullet #4? Bullet #4 seems to suggest that it is mandatory to implement all of Section 6.1 (of which proximity checks in Section 6.1.1 is a subset) if it applies to the relevant use case/architecture/protocol while bullet #5 appears to say that it is merely a recommendation (SHOULD). How does one implement both of these requirements at the same time consistently? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Paul Kyzivat for the GENART review. ** Section 6.1.1 * Physical connectivity: This is a good indicator of proximity, but requires specific ports, cables and hardware and may be challenging from a user experience perspective or may not be possible in certain settings (e.g., when USB ports are blocked or removed for security purposes). Physical connectivity may be better suited to dedicated hardware like FIDO devices that can be used with protocols that are resistant to the exploits described in this document. Doesn’t requiring one to plug into something, specifically if there is a data channel, present some risks with certain hardware (e.g., USB) ** Section 6.1.14 It SHOULD be clear to the user how to decline the request. Are there usecases or desirable user experience designs where it is optimal for the user to be unclear on how to decline a request? I also note that what is “clear” seems subjective given the huge variability in the “user” population. ** Reference [FIDOCTAP22] Bradley, J., Jones, M.B., Kumar, A., Lindemann, R., Verrept, S., and D. Waite, "Client to Authenticator Protocol (CTAP)", July 2025. Please provide more detail in this reference. This citation provides no indication that this is a FIDO standard or which version applies. Looking at https://fidoalliance.org/specifications/download/, it looks like there are various versions such as: V2.1 = https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html V2.2 = https://fidoalliance.org/specs/fido-v2.2-ps-20250714/fido-client-to-authenticator-protocol-v2.2-ps-20250714.html _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
