Roman Danyliw has entered the following ballot position for draft-ietf-regext-rdap-openid-25: 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-regext-rdap-openid/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 3.1.3. Lining up flow in Figure 2 and the associated text, it appears that the RDAP client passes the access token to the RDAP server (Step #10) which the RDAP server then passes it to the OpenID provider (Step #11). My understanding is that it is not considered good practice to pass access tokens to external parties. Is there a reason that RFC7667 (OAuth Token Introspection) could not be used to allow the RS to query the AS about the various claims? ** Section 3.1.5.2. By design, this section seems to be defining a mechanism outside of normal any audit capabilities which seems like it could have security and operational implications. Being able to track who is making queries seems fundamental to operating the RDAP system. Please document the associated risks of being blind to certain queries. ** Section 5.1.2. This workflow and even the fields in the farv1_deviceInfo data structure seem to be very similar to the RFC8628/OAuth Device Authorization Grant. Did the WG consider using this flow instead of this custom one? Could it be used instead? ** Section 5.2.4.2. The polling behavior described here is said to confirm to the “polling function described in RFC 8628 [RFC8628]”. However, this section seems to specify normative behavior around query strings, that is, using an HTTP GET method. Section 3.1 of RFC8628 states that the protocol flow needs to use a POST method. ** Section 11 Additionally, the practices described in RFC 8996 [RFC8996] MUST be followed when the Transport Layer Security (TLS) protocol is used. Not using TLS 1.0 and 1.1 seems to narrow in scope. Please use RFC 9325/BCP 195. ** Section 11. An RDAP server operator SHOULD develop policies for information disclosure to ensure that personally identifiable information is disclosed only to clients that are authorized to process that information. Why is this not a MUST? What are the circumstances where PII should be disclosed without authorization? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to the authors for reaching out to the OAuth WG when this document was first being drafted. Thank you to Justin Richer for providing a timely review of this work from the OAuth WG perspective. See https://mailarchive.ietf.org/arch/msg/oauth/33Ci5v7EHDLRC7pvvK85uarXutY/. Please review and respond to his feedback. A number of ballot positions presented here are due to his analysis. I appreciate the patience of the WG given my deferral of this document to this telechat. ** Section 3.1.3 The RDAP server can then make identification, authorization, and access control decisions based on End-User identity information and local policies. Note that OpenID Connect describes different process flows for other types of clients, such as script-based or command line clients. Is RDAP intended to support additional flows beyond those described here? ** Section 3.1.3 10. The RDAP client sends queries that require user identification, authentication, and authorization to an RDAP server that include an Access Token in an HTTP "Authorization" header using the "Bearer" authentication scheme. Please provide a normative reference to this authentication scheme. ** Section 3.1.5.1 Communities of RDAP users and operators may wish to make and validate claims about a user's "need to know" when it comes to requesting access to a protected resource. I don’t fully understand who will know what in the RDAP ecosystem. Will the identity provider be able to validate all of the allowable behaviors to validate the values of the “rdap_allowed_purposes” claim? ** Section 3.1.5.1. Editorial. Move all of the guidance on registry management to Section 9.3 ** Section 3.1.5.2. Not understanding the RDAP ecosystem and responding to the example, this section seems to be providing a privileged mechanism for law enforcement. Are there other users? Is this notion of “do not track” intended (or currently implemented) as a general-purpose mechanism? ** Section 5.1.1. Per the UserID value, is that created in some standardized way for the RDAP ecosystem to allow interoperability? OpenID uses a tuple of issuer and subject. ** Section 11. OpenID Connect defines optional mechanisms for robust signing and encryption that can be used to provide data integrity and data confidentiality services as needed. How would these services be used and for what purpose? ** Section 11 As described in Section 3.1.4.2, the OAuth 2.0 Implicit Flow [RFC6749] is considered insecure and efforts are being made to deprecate the flow. It SHOULD NOT be used. Since this is “green field” design, why not “MUST NOT”? ** Section 11. Would referencing draft-ietf-oauth-security-topics-23 for additional SecCon be useful? _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
