From nobody Thu Jul 7 06:13:19 2022 Return-Path: X-Original-To: regext@ietfa.amsl.com Delivered-To: regext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23967C15A72B for ; Thu, 7 Jul 2022 06:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pirorg.onmicrosoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfljKz91Qd-7 for ; Thu, 7 Jul 2022 06:13:13 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2169.outbound.protection.outlook.com [104.47.56.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDBEC15CF51 for ; Thu, 7 Jul 2022 06:13:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HQT7CLryx6QGAiPgNeh6xjL9grMwzFup1LVDkpBoybSBUdicS/7nIKCSmBQ3gu7s5LZ+fGYyxembzAcjxSxVL08yVjG8T3JxRNZ8Ick/LTtbDHY4uPIMr6l+UZuFBLXBEo+9kfvgTFD6jeoRpRq0uBE1Q5H476H72FVFNvlOE4s3521/TLqg0q5EVPxPt/uIO3qEgFaOsIRbjJtDsvvgP2dvzaf7oYyZcATiguZMaCzmfFqAOFvg7P+CpWuhRu9qFt7tZuUTC+t7e2P58mduAX+3MkHKs3meJ6/1tn70FUQvhyajWXpIdua7cjSrEWEPMxaj/movZvquTULTPbRXNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=kUc8T5+xbDryI57jXSfYGmpBdhzI6McVgHoIN+7Q1cI=; b=UkvvTv0xlDMUiGI7rd5LaxGpR/9AZm7RDi3hCMPf5kGPWP/YfCZBouMmxlwPCimDV5y1CrkUBiOuw0mQD8ZR4RCYZG4FB2WpKpE+DYDbrbpLX/w2gvR1IwVR3k3KuBf7Hu5tBoPSE+y1gHknPCm3/f65TRvN7TQCq3DS5p+5y1zD0tEJ4EKCaQgV+ePET69yUUXbvnSTXC9OP1AJQgcod95qvpUL/93KRD092wZp4msXYYKbY+Ne4WHZATH2TfXkzNcOn5Zg4jxkS8iOpo7EKSLT/m76X9JcG26VbUIIx67Vzoe7RFaj90iB58lJx3ZSM3r71Amb9EmaEfzidsaOhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=pir.org; dmarc=pass action=none header.from=pir.org; dkim=pass header.d=pir.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pirorg.onmicrosoft.com; s=selector2-pirorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kUc8T5+xbDryI57jXSfYGmpBdhzI6McVgHoIN+7Q1cI=; b=X1mXXiZMTAqtp1aefcYVzT/SjH/cIaKRmx3Oir9JmipaD8eGpJbBF6KdAt+iL0Rf2HRuj4s+GMk1yO6hpD8PSdy/7fLqQUus3ZxfSW3nYRrtPCisGKEgbpdQsXvk/7zL7NR32prHAvg57JkYr/JB9Qe8hjo+4Hner0lhqZI5okE= Received: from BY5PR10MB4179.namprd10.prod.outlook.com (2603:10b6:a03:206::8) by MWHPR1001MB2160.namprd10.prod.outlook.com (2603:10b6:301:36::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.16; Thu, 7 Jul 2022 13:13:08 +0000 Received: from BY5PR10MB4179.namprd10.prod.outlook.com ([fe80::1521:31a5:949b:8aee]) by BY5PR10MB4179.namprd10.prod.outlook.com ([fe80::1521:31a5:949b:8aee%4]) with mapi id 15.20.5417.016; Thu, 7 Jul 2022 13:13:08 +0000 From: Rick Wilhelm To: "Hollenbeck, Scott" , "regext@ietf.org" Thread-Topic: [regext] I-D Action: draft-ietf-regext-rdap-openid-15.txt Thread-Index: AQHYkgNNh763yo9xjkeU+FKYsSnb2Q== Date: Thu, 7 Jul 2022 13:13:08 +0000 Message-ID: References: <165540128008.60709.5285260183313271799@ietfa.amsl.com> <7ca7afff4039420ca54cff618f824898@verisign.com> In-Reply-To: <7ca7afff4039420ca54cff618f824898@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=PIR.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c91639a4-460f-44b2-71c0-08da601a6f8c x-ms-traffictypediagnostic: MWHPR1001MB2160:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fhueD3Zc68hMTqdcbjnye2PcNLbeDgd4IFvK8IUl8XUiS2YYdTEQdskxagHXK0+UO/gEWutD0No66vYuGaO4x8uuSNkN6VHhFtPbabn4ovjeL1whw1jiBjWtt2Uvnkg7y0oYilVc3HsK5ZY+y2gK9PGDYT7l2NSgq57su4Tc3q6RdgGT0MHBHsaxRQkXttE5Ze6gE3BmvyrkrsAPRxmT8731K8mNs0A1F1WQt+JSL+ASkrpNccat7YAzmOcqs0XL6w4NGCVAxTF4PxnDD9MalhdHD7g4gbIzrj9qzsUk62QZghS/cD37FBGS8lY7iBKXPhzK8NJCODHLxsiZyKZqRbOpK9VY27SJSnI5U12DkdfdtlimTzGNggGkaxPPUFCY4ykMqt+mvrDz+WOnqECWkCQDvm0Laepqtpk/m6vjjG10QGxXozd5yvZNqPp8FSzWV2FQ7bYXy92fXzLpsuY66BDP+zGTYR7XwZAKu4e6G+QrNT1vkiVtM/0lVmgpNmS1ikEcsCUKjnXDNEPIn10g5BPpQBK3duu0HtkhMZlvdcHZAel/28qfyny+6LhM0y6+8w8NfnBunkq6Am0Q1OXl74Ijd27qv/UgtdsnRFYwdomR1o2ptBSgvnkwcTqlUN4gvuR+te9nKF1Y4HTIamJUrdQ/A1gXcTZuD9E9m2MqR2lxNG9rtmxCSxizSieKjSL90DT4Gh5Zl3nCtQO5GnZvFCKJ6/wfZbi8iqQWB8dt/PhLhtQjlMESXEcYyVHdK60UtxP0uGGaeCWTo5x9y+ilri82tWzyGntpfpqZqv4Ah+pqVyutbYUmIg3zU+TADyCL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR10MB4179.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(39840400004)(366004)(136003)(376002)(396003)(346002)(55016003)(9686003)(110136005)(186003)(83380400001)(38100700002)(122000001)(26005)(66574015)(64756008)(7696005)(86362001)(33656002)(8676002)(6506007)(66476007)(66446008)(66556008)(2906002)(66946007)(53546011)(38070700005)(41300700001)(8936002)(316002)(52536014)(76116006)(91956017)(71200400001)(5660300002)(478600001)(30864003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?xKJ9Mol1dt+OxOgP98khIG6VEvW+iHzIjJpq1q+i5tnlOOrfhza3goJa?= =?Windows-1252?Q?7fxG8pNUt7ROfANr4AJ41Vm1t8UhWpXFQdoqjkYHH1wjMtxmJ/gL49+0?= =?Windows-1252?Q?RyIKcY2izq6kROfM5tjzcoKMzfuIQ/MrpMamgRGNGHENinJjrFht+F2q?= =?Windows-1252?Q?lgO776RuU+bvgJvA4j86tqu5Ut3vYx0szBNSnE9ZDquoSZEMt1k/G1QI?= =?Windows-1252?Q?GDtKzg92eMlosAr4AMgR+dzNvAAqwIPHwwJiui4oofodmUgIB/ZaHWkI?= =?Windows-1252?Q?EpwRitOPjV8lp6pxiCUUmUPhtUhT/W+oPGXxGXeDCfPZwDK2UaZI9BxW?= =?Windows-1252?Q?/thu6X0ITCAEBnuMd6S9h0GPbE1VHV33SdeA4Rhq3PNnE00tSaj9TTq8?= =?Windows-1252?Q?jTpYz/Xw7cUXUwjtAukBVUpnubTpQZ8JLkQKB+sqmTd5qZnPxyu2jQuq?= =?Windows-1252?Q?zVlUOt70c8nFRSx9/EbmL0JXjZ1Kti6uQCTGEiY+og88qXksHRhCvC5Q?= =?Windows-1252?Q?ZvJ9CJb6ZsryjHH6vJg2hnAy4iRmC+QFM1jTbyo63Vy4ngt5w9pvOWFX?= =?Windows-1252?Q?ve+MWf4FjayxW8Ij7g5+v0lnDVWfgdwT4tpFYbwwX/H0pmVW2DzQuBIH?= =?Windows-1252?Q?8qqMqSz2XESn5gixjDEbGZIJVjJWN5jIaZhzhqIb1EimjOZ0l0lAJJGY?= =?Windows-1252?Q?eDYB1MtNRxO3a7X6me0PNokkzcnTkdSVFtrkztr1obPC/MyLGlSTTQmS?= =?Windows-1252?Q?GJn2lZOKdFnWPQz8T8rYaYWYtcrrTTeTlHwnId2kxOMcGwvb5H2JAb/j?= =?Windows-1252?Q?JY8+mPCIaWn5o8A8nZaq4yH7YCHlmwSKvw6bdDn8z4FQZKOX1cM193+4?= =?Windows-1252?Q?BDGMAtQBPzCuH62B+KX5IyHGxRUqHi0iOhtN1PbU4yr3Bdx5tgW145E/?= =?Windows-1252?Q?LYshFj7Ambo0Qz+YV43QZVfYjoHH+VbjdO+Aisdeu7VwI1BcnBBHHShc?= =?Windows-1252?Q?OUKumL3CfgGLVol01HQHe5GZLSeQ2PTsie9oxD6SkjY5JWQqsnSBnSHj?= =?Windows-1252?Q?+aL7PkDY6TzmU5BayFjWXzGHM/e1uh4/vrm8nHOKyq3+dz+NuJ/SYUbi?= =?Windows-1252?Q?tCtf1xHHriEiNF8hVFecqpST70OBS3llBlm9RI1CalAlX/53mFQY1mNd?= =?Windows-1252?Q?xL5IK3EX1jbyLGnJKv/9bYIXc5J4zO3KYVLUymdKGlxn7x039l/6/a2C?= =?Windows-1252?Q?COYUbAes7yRc0wGYttw5GcduAhp8mfBpcS/O5AQXlF4pNgl3224aP+7N?= =?Windows-1252?Q?D/64i23S3p1JothQCv287DLycduFQEK1gPWq9etx6qHzUbU0Q4vzomoU?= =?Windows-1252?Q?BVW58oM5lpj/uF9RiSpn94fo3BFpwhnyCUZQHSFt1XtrxhE6wnt0bI9v?= =?Windows-1252?Q?9x8QiySWIf7Zae3hSFAD5GfOTm4FAMma2eKZRLr2+D1ts3IKvOVuZpMU?= =?Windows-1252?Q?JhIgaX9Cya4i0Ms8ms46glCyEBmzzIwRuKRiI7nRaD+IBImErJJJL1/Z?= =?Windows-1252?Q?I82RCo8soa6TmU+/WCrXjyYaiHIbVyaJJESSNkxD7/dsCBOm6ZXJp4tR?= =?Windows-1252?Q?hDrkgxb6Vux7ZxfxUna0yD9d3+w3qHwt8biyUDx6amAJ9FqI8wf4t7sM?= =?Windows-1252?Q?tQQ1MsWRM9eLNf6dixME279l7cEFgtt+?= Content-Type: multipart/alternative; boundary="_000_BY5PR10MB417901DF0200F66570832825C9839BY5PR10MB4179namp_" MIME-Version: 1.0 X-OriginatorOrg: pir.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4179.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c91639a4-460f-44b2-71c0-08da601a6f8c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2022 13:13:08.2612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6c8ced78-b98f-4fa4-b6df-38beaa0d935d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1/p3Dd0yBNfS08nSdmWonCedeBrh4/e53kHxlwdmMaiWcpyk3i+JBoo1WyCystj7EHAWYZ6+tbZm0wBJfY10tQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1001MB2160 Archived-At: Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-15.txt X-BeenThere: regext@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Registration Protocols Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2022 13:13:18 -0000 --_000_BY5PR10MB417901DF0200F66570832825C9839BY5PR10MB4179namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, A brief response to the Section 4.5 item, you can search for =93[RW]=94 to = find it quickly. And the suggested edit for Section 5 looks great. Also marked for clarity. Thanks, Rick From: Hollenbeck, Scott Date: Tuesday, July 5, 2022 at 2:17 PM To: Rick Wilhelm , regext@ietf.org Subject: [EXTERNAL] RE: [regext] I-D Action: draft-ietf-regext-rdap-openid-= 15.txt CAUTION: This email came from outside your organization. Don=92t trust emai= ls, links, or attachments from senders that seem suspicious or you are not = expecting. ________________________________ Notes below, Rick. Thanks for the feedback. From: Rick Wilhelm Sent: Thursday, June 23, 2022 4:07 PM To: regext@ietf.org; Hollenbeck, Scott Subject: [EXTERNAL] Re: [EXTERNAL] [regext] I-D Action: draft-ietf-regext-r= dap-openid-15.txt Caution: This email originated from outside the organization. Do not click = links or open attachments unless you recognize the sender and know the cont= ent is safe. Scott, Thanks for your ongoing work on rdap-openid. I am, by no measure, an exper= t in OpenID, so some (all?) of this feedback may miss the mark. But perhap= s some will be helpful. I don=92t think that any of the below is new to the -15 version. (The seco= nd item is from -14). But I=92m hoping that this feedback helps to move th= is draft forward, as I think that it=92s an important step for RDAP. These are in the order provided in the doc, not in any order of importance. First some more macro things: Section 3.1.1: Terminology For this section, which currently focuses on RDAP terminology, I think that= it would be helpful echo something like the terminology section of RFC 841= 4 (an Informative Reference from 12.2). Pasting a snippet=85 This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]; the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [JWT]; (I=92ll offer that JWT :=3D RFC 7519, already a Normative Reference.) The = actual text would need a careful edit, I just pasted this. [SAH] OK, good idea. I=92ll add this and check the term set. Section 4.5: Regarding the text: Alternatively, an RDAP server MAY implicitly attempt to refresh an access token upon receipt of a query if the access token associated with an existing session has expired and the corresponding OP supports token refresh. The default RDAP server behavior is described in the "implicitTokenRefreshSupported" value that's include in the "roidc1_openidcConfiguration" data structure (see Section 4.1.3). If the value of "implicitTokenRefreshSupported" is "true", the client MAY either explicitly attempt to refresh the session using the "roidc1_session/refresh" query, or it MAY depend on the RDAP server to implicitly attempt to refresh the session as necessary when an RDAP query is received by the server. If the value of "implicitTokenRefreshSupported" is "false", the client MUST explicitly attempt to refresh the session using the "roidc1_session/ refresh" query to extend an existing session. If a session cannot be extended for any reason, the client MUST establish a new session to continue authenticated query processing by submitting a "roidc1_session/login" query. If the OP does not support token refresh, the client MUST submit a new "roidc1_session/login" request to establish a new session once an access token has expired. If the server has =93true=94 for =93implicitTokenRefreshSupported=94, there= doesn=92t seem to be a MUST requirement on the server to actually attempt = a refresh. Is that on purpose? [SAH] No, I=92ll add a =93MUST=94. In the last sentence: Is the client required to wait until the access token= has expired before submitting the new login request? Or can it send logou= t and login back-to-back? (Or even just a login command while currently lo= gged in?) [SAH] Let=92s talk about this. What=92s appropriate behavior? IF the server= gets a =93login=94 during an active session, it can either ignore the seco= nd =93login=94, or it can return an error. Similarly, it the server gets a = =93logout=94 when there=92s no active session, it can either ignore the =93= logout=94 or return an error. I=92m inclined to return an error to explicit= ly note that the submitted query/command wasn=92t processed as requested. [RW] First off, I will certainly defer to those with more implementation in= this realm. However, based on my experience as a user, I would expect a l= ogin that happens during an active session to =93just work=94 and override = the previous active session. This could happen when I have an active sessi= on at the server but the client browser (with the session) crashes or is ot= herwise inaccessible. This seems better than the alternative: If the new = login request is refused, then the user is (essentially) locked out until t= he session timeout value expires. Related, if the server gets a =93logout= =94 when there is no active session, I think that it should ignore the =93l= ogout=94 (rather than returning an error). The thinking being that returni= ng an error is at best useless and at worst could be an information leak (a= ka security risk). Nit: This block might be easier to parse if broken into multiple paragraph= s. [SAH] Will do. Section 10. Security Considerations: This section defers the security considerations for OIDCC to that specifica= tion. Section 3.1.2 contains the statement: =93Communication with the Aut= horization Endpoint MUST use TLS.=94 Section 5.3 makes a similar statement = related to the UserInfo Endpoint However, due to its publication date (2014= ) the document does not appear to have a prohibition on older versions of T= LS. Perhaps there should be some mention of BCP 195 (RFC 8996) in this dra= ft? [SAH] Agreed! Will add. Now on to nits/semi-nits: Section 3.1.3.1: para 3: Regarding: An RDAP server MUST support at least one of these methods of OP discovery. I think that would be more clear as: An RDAP server/RP MUST support at least one of these methods of OP discovery. (which would be consistent with para 1 in this section). The main point is= that we don=92t want to imply that all RDAP servers need to support this. = You might choose to clarify by just switching to =93RP=94? [SAH] I=92ll make the change to =93RDAP server/RP=94. Section 3.1.3.3: I think that for clarity, it would be helpful to use the word =93consent=94= somewhere in the first sentence of this section. This makes for stronger = linkage with 3.1.2 Step 6 and the heading in OIDCC 3.1.2.4. [SAH] OK, I=92ll change the first sentence to =93After the End-User is auth= enticated, the OP MUST obtain consent from the End-User to release authoriz= ation information to the RDAP Server/RP.=94. Section 3.1.3.4: Regarding: After the End-User is authenticated, the OP will send a response to the RP that describes the result of the authorization process in the form of an Authorization Grant. The beginning of the sentence seems to focus on authentication (not authori= zation) and only on the successful path. It also uses the term =93Authoriz= ation Grant=94, which is inconsistent with 3.1.2 Step 7 and my reading of O= IDCC 3.1.1. Suggest clarifying with: After obtaining an authorization result, the OP will send a response to the RP that provides the result of the authorization process using an Authorization Code. [SAH] Agreed, I=92ll make that change. Section 3.1.3.5: Regarding: The RP MUST validate the Token Response. This process is described in Section 3.1.3 of the OpenID Connect Core protocol [OIDCC]. I think that the reference could be more specific and point to OIDC 3.1.3.5 [SAH] OK. Section 3.1.3.6: Regarding: The set of claims can be retrieved by sending a request to a UserInfo Endpoint using the Access Token. The claims MAY be returned in the ID Token. I think that the structure of the second sentence and the use of the capita= lized =93MAY=94 doesn=92t quite capture the intent. My read of OIDCC 5.3 i= ndicates that the UserInfo Endpoint is not required to return UserInfo Clai= ms (for various reasons), but if they are going to be returned, they are go= ing to be returned in the ID Token. Perhaps replace the second sentence with: The server provides returned claims in the ID Token. [SAH] Agreed. Section 3.1.4: Regarding: OpenID Connect claims are pieces of information used to make assertions about an entity. Section 5 of the OpenID Connect Core protocol [OIDCC] describes a set of standard claims that can be used to identify a person. My read of OIDCC Section 5 didn=92t indicate anything about a person. Sugg= est the following edit: OpenID Connect claims are pieces of information used to make assertions about an entity. Section 5 of the OpenID Connect Core protocol [OIDCC] describes a set of standard claims. (Which also happens to align with OIDCC 5.1, almost verbatim.) [SAH] Agreed. Section 3.1.4.1: Regarding: There are communities of RDAP users and operators who wish to make and validate claims about a user's "need to know" when it comes to requesting access to a resource. For example, a law enforcement agent or a trademark attorney may wish to be able to assert that they have a legal right to access a protected resource, and a server operator will need to be able to receive and validate that claim. Suggest minor edits to avoid needing to support certain statements. As in: 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 resource. For example, a law enforcement agent or a trademark attorney may wish to be able to assert that they have a legal right to access a protected resource, and a server operator may need to be able to receive and validate that claim. [SAH] Agreed. Section 3.1.4.2: Regarding: There are also communities of RDAP users and operators who wish to make and validate claims about a user's wish to not have their queries logged, tracked, or recorded. For example, a law enforcement agent may wish to be able to assert that their queries are part of a criminal investigation and should not be tracked due to a risk of query exposure compromising the investigation, and a server operator will need to be able to receive and validate that claim. As above, suggest minor edits to avoid needing to support certain statement= s. As in: Communities of RDAP users and operators may wish to make and validate claims about a user's wish to not have their queries logged, tracked, or recorded. For example, a law enforcement agent may wish to be able to assert that their queries are part of a criminal investigation and should not be tracked due to a risk of query exposure compromising the investigation, and a server operator may need to be able to receive and validate that claim. [SAH] Agreed. Section 4.3.1: Regarding: If this parameter is not present, the server MUST proces the query and make an acces control decision based on any other information known to the server about the End-User and the information they are requesting. Suggested minor edit to remove the ambiguity of =93this parameter=94 (and f= ix two typos) If the =93roidc1_qp=94 parameter is not present, the server MUST process the query and make an access control decision based on any other information known to the server about the End-User and the information they are requesting. [SAH] Agreed. Section 4.6: Regarding: The server should also take appropriate steps to ensure that the tokens associated with the terminated session cannot be reused. Suggest an edit to move this =93should=94 to =93SHOULD=94 [SAH] Agreed. Section 4.7: Regarding: Servers MUST reject queries that include identification information that is not associated with a supported OP by returning an HTTP 501 (Not Implemented) response. For clarity, suggest adding =93RDAP=94 before =93Servers=94=85 as in: RDAP servers MUST reject queries that include identification information that is not associated with a supported OP by returning an HTTP 501 (Not Implemented) response. (Or if this doesn=92t refer to the RDAP Server, then something else to disa= mbiguate.) [SAH] Agreed. Section 5: Regarding: ID tokens include an audience parameter that contains the OAuth 2.0 client_id of the RP as an audience value. >From my read of OIDCC Section 2 (=93ID Token=94), it appears that this =93a= udience parameter=94 refers to an item that is described as a =93claim=94 i= n that document. However, later in Section 5, there is a reference to RFC 8693, which in Sec= tion 2.1 describes an =93audience parameter=94. So, I=92m not sure which is correct=85 perhaps something to direct the read= er. (Or maybe they are largely equivalent and my ignorance is on full disp= lay!) [SAH] They=92re related to each other (8693 describes the request, OIDCC de= scribes the output), but yes, the ID Token contains a claim so the text can= be clarified. How about this: =93ID tokens include an "aud" (audience) claim that contains the OAuth 2.0 = client_id of the RP as an audience value. In some operational scenarios (su= ch as a client that is providing a proxy service), an RP can receive tokens= with an "aud" value that does not include the RP's client_id. These tokens= might not be trusted by the RP, and the RP might refuse to accept the toke= ns. This situation can be remedied by having the RP exchange these tokens w= ith the OP for a set of trusted tokens that reset the "aud" claim.=94 [RW] Good upgrade! Hope these help=85 Thanks, Rick --_000_BY5PR10MB417901DF0200F66570832825C9839BY5PR10MB4179namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Scott,

 

A brief response to= the Section 4.5 item, you can search for =93[RW]=94 to find it quickly.

 

And the suggested e= dit for Section 5 looks great.  Also marked for clarity.

 

Thanks,<= /span>

Rick

 

From: Hollenbeck, Scott &= lt;shollenbeck@verisign.com>
Date: Tuesday, July 5, 2022 at 2:17 PM
To: Rick Wilhelm <Rwilhelm@PIR.org>, regext@ietf.org <regex= t@ietf.org>
Subject: [EXTERNAL] RE: [regext] I-D Action: draft-ietf-regext-rdap-= openid-15.txt

CAUTION: This email came from outsi= de your organization. Don=92t trust emails, links, or attachments from send= ers that seem suspicious or you are not expecting.

Notes below, Rick. = Thanks for the feedback.

 <= /o:p>

From:= Rick Wilhelm <Rwilhelm@PIR.org>
Sent: Thursday, June 23, 2022 4:07 PM
To: regext@ietf.org; Hollenbeck, Scott <shollenbeck@verisign.com&= gt;
Subject: [EXTERNAL] Re: [EXTERNAL] [regext] I-D Action: draft-ietf-r= egext-rdap-openid-15.txt

 

Caution: <= /span>This email originated from outside the organization. Do not click links or open= attachments unless you recognize the sender and know the content is safe.&= nbsp;

Scott,<= /span>

 <= /o:p>

Thanks for your ong= oing work on rdap-openid.  I am, by no measure, an expert in OpenID, s= o some (all?) of this feedback may miss the mark.  But perhaps some wi= ll be helpful. 

 <= /o:p>

I don=92t think tha= t any of the below is new to the -15 version.  (The second item is fro= m -14).  But I=92m hoping that this feedback helps to move this draft = forward, as I think that it=92s an important step for RDAP.

 <= /o:p>

These are in the or= der provided in the doc, not in any order of importance.<= /p>

 <= /o:p>

First some more mac= ro things:

 <= /o:p>

Section 3.1.1: = ; Terminology

 <= /o:p>

For this section, w= hich currently focuses on RDAP terminology, I think that it would be helpfu= l echo something like the terminology section of RFC 8414 (an Informative R= eference from 12.2).    Pasting a snippet=85

 <= /o:p>

   This s= pecification uses the terms "Access Token", "Authorization

   Code&q= uot;, "Authorization Endpoint", "Authorization Grant",<= /span>

   "= Authorization Server", "Client", "Client Authentication= ", "Client

   Identi= fier", "Client Secret", "Grant Type", "Protec= ted Resource",

   "= Redirection URI", "Refresh Token", "Resource Owner"= ;, "Resource

   Server= ", "Response Type", and "Token Endpoint" defined b= y OAuth 2.0

   [RFC67= 49]; the terms "Claim Name", "Claim Value", and "J= SON Web Token

   (JWT)&= quot; defined by JSON Web Token (JWT) [JWT];

 <= /o:p>

(I=92ll offer that = JWT :=3D RFC 7519, already a Normative Reference.)  The actual text wo= uld need a careful edit, I just pasted this.

 <= /o:p>

[SAH] OK, goo= d idea. I=92ll add this and check the term set.

 <= /o:p>

Section 4.5:=

 <= /o:p>

Regarding the text:=

 <= /o:p>

   Altern= atively, an RDAP server MAY implicitly attempt to refresh an

   access= token upon receipt of a query if the access token associated

   with a= n existing session has expired and the corresponding OP

   suppor= ts token refresh.  The default RDAP server behavior is

   descri= bed in the "implicitTokenRefreshSupported" value that's include

   in the= "roidc1_openidcConfiguration" data structure (see

   Sectio= n 4.1.3).  If the value of "implicitTokenRefreshSupported" i= s

   "= true", the client MAY either explicitly attempt to refresh the<= o:p>

   sessio= n using the "roidc1_session/refresh" query, or it MAY depend on

   the RD= AP server to implicitly attempt to refresh the session as=

   necess= ary when an RDAP query is received by the server.  If the value=

   of &qu= ot;implicitTokenRefreshSupported" is "false", the client MUS= T

   explic= itly attempt to refresh the session using the "roidc1_session/<= o:p>

   refres= h" query to extend an existing session.  If a session cannot be

   extend= ed for any reason, the client MUST establish a new session to

   contin= ue authenticated query processing by submitting a

   "= roidc1_session/login" query.  If the OP does not support token

   refres= h, the client MUST submit a new "roidc1_session/login" request

   to est= ablish a new session once an access token has expired.

 <= /o:p>

If the server has = =93true=94 for =93implicitTokenRefreshSupported=94, there doesn=92t seem to= be a MUST requirement on the server to actually attempt a refresh.  &= nbsp;Is that on purpose? 

[SAH] No, I= =92ll add a =93MUST=94.

 <= /o:p>

In the last sentenc= e: Is the client required to wait until the access token has expired before= submitting the new login request?  Or can it send logout and login ba= ck-to-back?  (Or even just a login command while currently logged in?)

[SAH] Let=92s= talk about this. What=92s appropriate behavior? IF the server gets a =93lo= gin=94 during an active session, it can either ignore the second =93login= =94, or it can return an error. Similarly, it the server gets a =93logout=94 when there=92s no active session, it can either= ignore the =93logout=94 or return an error. I=92m inclined to return an er= ror to explicitly note that the submitted query/command wasn=92t processed = as requested.

 

[RW] First off, I w= ill certainly defer to those with more implementation in this realm.  = However, based on my experience as a user, I would expect a login that happ= ens during an active session to =93just work=94 and override the previous active session.  This could happen when I h= ave an active session at the server but the client browser (with the sessio= n) crashes or is otherwise inaccessible.  This seems better than the a= lternative:  If the new login request is refused, then the user is (essentially) locked out until the session timeout value = expires.  Related, if the server gets a =93logout=94 when there is no = active session, I think that it should ignore the =93logout=94 (rather than= returning an error).  The thinking being that returning an error is at best useless and at worst could be an information= leak (aka security risk).

 

Nit:  This blo= ck might be easier to parse if broken into multiple paragraphs.=

[SAH] Will do= .

 <= /o:p>

Section 10.  S= ecurity Considerations:

 <= /o:p>

This section defers= the security considerations for OIDCC to that specification.  Section= 3.1.2 contains the statement:  =93Communication with the Authorizatio= n Endpoint MUST use TLS.=94 Section 5.3 makes a similar statement related to the UserInfo Endpoint However, due to its publication= date (2014) the document does not appear to have a prohibition on older ve= rsions of TLS.  Perhaps there should be some mention of BCP 195 (RFC 8= 996) in this draft?

[SAH] Agreed!= Will add.

 <= /o:p>

 <= /o:p>

Now on to nits/semi= -nits:

 <= /o:p>

Section 3.1.3.1:&nb= sp; para 3:

 <= /o:p>

Regarding: <= o:p>

An RDAP server MUST= support at least one of these

   method= s of OP discovery.

 <= /o:p>

I think that would = be more clear as:

An RDAP server/RP M= UST support at least one of these

   method= s of OP discovery.

(which would be con= sistent with para 1 in this section).  The main point is that we don= =92t want to imply that all RDAP servers need to support this.  You mi= ght choose to clarify by just switching to =93RP=94?

[SAH] I=92ll = make the change to =93RDAP server/RP=94.

 <= /o:p>

 <= /o:p>

Section 3.1.3.3:

 <= /o:p>

I think that for cl= arity, it would be helpful to use the word =93consent=94 somewhere in the f= irst sentence of this section.  This makes for stronger linkage with 3= .1.2 Step 6 and the heading in OIDCC 3.1.2.4.

[SAH] OK, I= =92ll change the first sentence to =93After the End-User is authenticated, = the OP MUST obtain consent from the End-User to release authorization infor= mation to the RDAP Server/RP.=94.

 <= /o:p>

 <= /o:p>

Section 3.1.3.4:

 <= /o:p>

Regarding: <= o:p>

   A= fter the End-User is authenticated, the OP will send a response to

   the RP= that describes the result of the authorization process in the<= /o:p>

   form o= f an Authorization Grant.

 <= /o:p>

The beginning of th= e sentence seems to focus on authentication (not authorization) and only on= the successful path.  It also uses the term =93Authorization Grant=94= , which is inconsistent with 3.1.2 Step 7 and my reading of OIDCC 3.1.1.  Suggest clarifying with:

 <= /o:p>

   After = obtaining an authorization result, the OP will send a response to

  the RP that = provides the result of the authorization process using an=

  Authorizatio= n Code.

[SAH] Agreed,= I=92ll make that change.

 <= /o:p>

 <= /o:p>

Section 3.1.3.5:

 <= /o:p>

Regarding:

 <= /o:p>

The RP MUST validat= e the Token

   Respon= se.  This process is described in Section 3.1.3 of the OpenID

   Connec= t Core protocol [OIDCC].

 <= /o:p>

I think that the re= ference could be more specific and point to OIDC 3.1.3.5<= /p>

[SAH] OK.

 <= /o:p>

 <= /o:p>

Section 3.1.3.6:

 <= /o:p>

Regarding:

 <= /o:p>

   The se= t of claims can be retrieved by sending a request to a UserInfo=

   Endpoi= nt using the Access Token.  The claims MAY be returned in the

   ID Tok= en.

 <= /o:p>

I think that the st= ructure of the second sentence and the use of the capitalized =93MAY=94 doe= sn=92t quite capture the intent.  My read of OIDCC 5.3 indicates that = the UserInfo Endpoint is not required to return UserInfo Claims (for various reasons), but if they are going to be returne= d, they are going to be returned in the ID Token.

 <= /o:p>

Perhaps replace the= second sentence with:

   The se= rver provides returned claims in the ID Token.

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 3.1.4:

 <= /o:p>

Regarding: <= o:p>

 <= /o:p>

   OpenID= Connect claims are pieces of information used to make

   assert= ions about an entity.  Section 5 of the OpenID Connect Core

   protoc= ol [OIDCC] describes a set of standard claims that can be used<= /o:p>

   to ide= ntify a person. 

 <= /o:p>

My read of OIDCC Se= ction 5 didn=92t indicate anything about a person.  Suggest the follow= ing edit:

 <= /o:p>

   OpenID= Connect claims are pieces of information used to make

   assert= ions about an entity.  Section 5 of the OpenID Connect Core

   protoc= ol [OIDCC] describes a set of standard claims.

 <= /o:p>

(Which also happens= to align with OIDCC 5.1, almost verbatim.)

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 3.1.4.1:

 <= /o:p>

Regarding: <= o:p>

 <= /o:p>

   There = are communities of RDAP users and operators who wish to make

   and va= lidate claims about a user's "need to know" when it comes to

   reques= ting access to a resource.  For example, a law enforcement=

   agent = or a trademark attorney may wish to be able to assert that they=

   have a= legal right to access a protected resource, and a server=

   operat= or will need to be able to receive and validate that claim.

 <= /o:p>

Suggest minor edits= to avoid needing to support certain statements.  As in:

 <= /o:p>

   Commun= ities of RDAP users and operators may wish to make

   and va= lidate claims about a user's "need to know" when it comes to

   reques= ting access to a resource.  For example, a law enforcement=

   agent = or a trademark attorney may wish to be able to assert that they=

   have a= legal right to access a protected resource, and a server=

   operat= or may need to be able to receive and validate that claim.

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 3.1.4.2:

 <= /o:p>

Regarding:

 <= /o:p>

   There = are also communities of RDAP users and operators who wish to

   make a= nd validate claims about a user's wish to not have their<= /p>

   querie= s logged, tracked, or recorded.  For example, a law enforcement=

   agent = may wish to be able to assert that their queries are part of a<= /o:p>

   crimin= al investigation and should not be tracked due to a risk of

   query = exposure compromising the investigation, and a server operator<= /o:p>

   will n= eed to be able to receive and validate that claim.

 <= /o:p>

As above, suggest m= inor edits to avoid needing to support certain statements.  As in:

 <= /o:p>

   Commun= ities of RDAP users and operators may wish to

   make a= nd validate claims about a user's wish to not have their<= /p>

   querie= s logged, tracked, or recorded.  For example, a law enforcement=

   agent = may wish to be able to assert that their queries are part of a<= /o:p>

   crimin= al investigation and should not be tracked due to a risk of

   query = exposure compromising the investigation, and a server operator<= /o:p>

   may ne= ed to be able to receive and validate that claim.

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 4.3.1:

 <= /o:p>

Regarding:

 <= /o:p>

If this parameter i= s not present, the server

   MUST p= roces the query and make an acces control decision based on any=

   other = information known to the server about the End-User and the

   inform= ation they are requesting.

 <= /o:p>

Suggested minor edi= t to remove the ambiguity of =93this parameter=94 (and fix two typos)

 <= /o:p>

If the =93roidc1_qp= =94 parameter is not present, the server

   MUST p= rocess the query and make an access control decision based on any

   other = information known to the server about the End-User and the

   inform= ation they are requesting.

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 4.6:=

 <= /o:p>

Regarding:

 <= /o:p>

   The se= rver should also take appropriate steps to ensure that the

   tokens= associated with the terminated session cannot be reused. 

 <= /o:p>

Suggest an edit to = move this =93should=94 to =93SHOULD=94

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 4.7:=

 <= /o:p>

Regarding:

 <= /o:p>

Servers MUST reject= queries

   that i= nclude identification information that is not associated with a=

   suppor= ted OP by returning an HTTP 501 (Not Implemented) response. 

 <= /o:p>

For clarity, sugges= t adding =93RDAP=94 before =93Servers=94=85 as in:

 <= /o:p>

RDAP servers MUST r= eject queries

   that i= nclude identification information that is not associated with a=

   suppor= ted OP by returning an HTTP 501 (Not Implemented) response. 

 <= /o:p>

(Or if this doesn= =92t refer to the RDAP Server, then something else to disambiguate.)

[SAH] Agreed.=

 <= /o:p>

 <= /o:p>

Section 5:

 <= /o:p>

Regarding:

 <= /o:p>

   ID tok= ens include an audience parameter that contains the OAuth 2.0

   client= _id of the RP as an audience value.

 <= /o:p>

From my read of OID= CC Section 2 (=93ID Token=94), it appears that this =93audience parameter= =94 refers to an item that is described as a =93claim=94 in that document.<= /span>

 <= /o:p>

However, later in S= ection 5, there is a reference to RFC 8693, which in Section 2.1 describes = an =93audience parameter=94.

 <= /o:p>

So, I=92m not sure = which is correct=85 perhaps something to direct the reader.  (Or maybe= they are largely equivalent and my ignorance is on full display!)

[SAH] They=92= re related to each other (8693 describes the request, OIDCC describes the o= utput), but yes, the ID Token contains a claim so the text can be clarified= . How about this:

 =

=93ID tokens = include an "aud" (audience) claim that contains the OAuth 2.0 cli= ent_id of the RP as an audience value. In some operational scenarios (such = as a client that is providing a proxy service), an RP can receive tokens with an "aud" value that does not inclu= de the RP's client_id. These tokens might not be trusted by the RP, and the= RP might refuse to accept the tokens. This situation can be remedied by ha= ving the RP exchange these tokens with the OP for a set of trusted tokens that reset the "aud" claim.=94

 

[RW] Good upgrade!<= o:p>

 <= /o:p>

Hope these help=85 =

 <= /o:p>

Thanks,=

 <= /o:p>

Rick

--_000_BY5PR10MB417901DF0200F66570832825C9839BY5PR10MB4179namp_--