Subject: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

From: [email-masked]
Date: Tue, 08 Feb 2022 10:52:50 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

        Title           : Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
        Author          : Scott Hollenbeck
	Filename        : draft-ietf-regext-rdap-openid-10.txt
	Pages           : 27
	Date            : 2022-02-08

Abstract:
   The Registration Data Access Protocol (RDAP) provides "RESTful" web
   services to retrieve registration metadata from domain name and
   regional internet registries.  RDAP allows a server to make access
   control decisions based on client identity, and as such it includes
   support for client identification features provided by the Hypertext
   Transfer Protocol (HTTP).  Identification methods that require
   clients to obtain and manage credentials from every RDAP server
   operator present management challenges for both clients and servers,
   whereas a federated authentication system would make it easier to
   operate and use RDAP without the need to maintain server-specific
   client credentials.  This document describes a federated
   authentication system for RDAP based on OpenID Connect.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-openid-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-openid-10

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 8 Feb 2022 18:57:35 +0000

> -----Original Message-----
> From: I-D-Announce <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Tuesday, February 8, 2022 1:53 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-10.txt
>
> Caution: 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.
>

[SAH] Please review this, folks. It's been significantly modified since version -09, replacing the token management queries with simpler login, logout, and session queries. This puts the draft in a much better position with respect to RDAP behaving like a web service, and it simplifies client processing, too.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Feb 2022 13:35:27 +0000

> From: regext <[email-masked]> On Behalf Of Hollenbeck, Scott
> Sent: Tuesday, February 8, 2022 1:58 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-
> 10.txt
> 
> > Caution: 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.
> >
> [SAH] Please review this, folks. It's been significantly modified since version -
> 09, replacing the token management queries with simpler login, logout, and
> session queries. This puts the draft in a much better position with respect to
> RDAP behaving like a web service, and it simplifies client processing, too.

[SAH] One thought for improvement: I just realized that the login query returns the claims that describe the end user, but not the complete set of information from the userinfo_endpoint. I missed that - it probably should.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Feb 2022 14:22:53 +0000

> Sent: Wednesday, February 9, 2022 8:35 AM
> To: [email-masked]
> > Subject: [EXTERNAL] Re: [regext] I-D Action:
> > draft-ietf-regext-rdap-openid- 10.txt
> >
> > [SAH] Please review this, folks. It's been significantly modified
> > since version - 09, replacing the token management queries with
> > simpler login, logout, and session queries. This puts the draft in a
> > much better position with respect to RDAP behaving like a web service, and
> it simplifies client processing, too.
>
> [SAH] One thought for improvement: I just realized that the login query
> returns the claims that describe the end user, but not the complete set of
> information from the userinfo_endpoint. I missed that - it probably should.

[SAH] Belay that: I just did some testing with two OpenID Providers and can confirm that the user information is included in the set of claims. I think this is covered.

Scott

---

From: Rick Wilhelm <[email-masked]>
Date: Wed, 9 Feb 2022 15:11:58 +0000

Scott,

Overall, I think that the modifications move the I-D in a good direction.  Thanks for your work on this.

I don’t have running code so this is more of a document review, rather than comments from an implementer perspective.

Pls see the below.

3.1.2:

NIT:  3.1.2 #2 uses the term ‘ “login” request’; while 4.1 uses term ‘ “login” query’ (line 1).

3.1.2:

EDITORIAL:  3.1.2 #2 (in sentence 2) includes a MUST condition (“MUST include an “id” query parameter)  for a server with only a remote Authorization Server.  However,  in 4.1, the MUST condition is more involved (has two options of delivery, not just the one mechanism described n 3.1.2) and is described as an “End-User identifier”.  Perhaps the text in sentence 2 of 3.1.2 can be aligned more closely to the text in 4.1 OR just reference 4.1 directly.

3.1.2.1:

EDITORIAL:  “, but that protocol is not widely implemented and can be unreliable.”  The text is not clear if the reliability issues are due to the lack of wide implementation or due to inherent reliability issues.  Suggest that “is not widely implemented” is sufficient for this use-case and the text “and can be unreliable” be struck.

6.  RDAP Conformance

EDITORIAL:  Last sentence of 4.1 para 1 says: “Clients can use either of these methods. Servers MUST support both methods.”  (Referring to local and remote client authentication.). However, Section 6, para 1, says “Both values MAY be present if a server supports both local and remote OpenID Authorization Servers.”   Thus, Section 6 implies that it’s possible that a server might not support both local and remote authentication.  Perhaps the solution would be to switch from “MAY” to “would” in section 6?

Happy to discuss any of the above.

Thanks,
Rick

From: regext <[email-masked]> on behalf of Hollenbeck, Scott <shollenbeck=[email-masked]>
Date: Tuesday, February 8, 2022 at 1:57 PM
To: [email-masked] <[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt
CAUTION: This email came from outside your organization. Don?t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.

Scott

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext<https://www.ietf.org/mailman/listinfo/regext>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Feb 2022 17:33:55 +0000

Thanks for the feedback, Rick! More below.

From: Rick Wilhelm <[email-masked]> 
Sent: Wednesday, February 9, 2022 10:12 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [EXTERNAL] Re: [regext] I-D Action:
draft-ietf-regext-rdap-openid-10.txt

Caution: 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. 

Scott,

Overall, I think that the modifications move the I-D in a good direction.
Thanks for your work on this.

I don't have running code so this is more of a document review, rather than
comments from an implementer perspective.

Pls see the below.  

3.1.2: 

NIT:  3.1.2 #2 uses the term ' "login" request'; while 4.1 uses term '
"login" query' (line 1).  

[SAH] It should be "query" consistently.

3.1.2:

EDITORIAL:  3.1.2 #2 (in sentence 2) includes a MUST condition ("MUST
include an "id" query parameter)  for a server with only a remote
Authorization Server.  However,  in 4.1, the MUST condition is more involved
(has two options of delivery, not just the one mechanism described n 3.1.2)
and is described as an "End-User identifier".  Perhaps the text in sentence
2 of 3.1.2 can be aligned more closely to the text in 4.1 OR just reference
4.1 directly.

[SAH] I'll remove the text from 3.1.2 and refer to 4.1.

3.1.2.1:

EDITORIAL:  ", but that protocol is not widely implemented and can be
unreliable."  The text is not clear if the reliability issues are due to the
lack of wide implementation or due to inherent reliability issues.  Suggest
that "is not widely implemented" is sufficient for this use-case and the
text "and can be unreliable" be struck.

[SAH] I'll strike "and can be unreliable".

6.  RDAP Conformance

EDITORIAL:  Last sentence of 4.1 para 1 says: "Clients can use either of
these methods. Servers MUST support both methods."  (Referring to local and
remote client authentication.). However, Section 6, para 1, says "Both
values MAY be present if a server supports both local and remote OpenID
Authorization Servers."   Thus, Section 6 implies that it's possible that a
server might not support both local and remote authentication.  Perhaps the
solution would be to switch from "MAY" to "would" in section 6?

[SAH] The "both methods" text refers to the client's options to send the
client identifier as either a query parameter OR in an authorization header.
It's not directly related to the text in Section 6, except to note that the
identifier is OPTIONAL and might not be present at all. I'll change the text
in Section 6 from "MAY" to "can", and will adjust both sections to make the
distinction clearer.

Thanks,

Rick

 

From: regext <[email-masked] <mailto:[email-masked]> > on
behalf of Hollenbeck, Scott <shollenbeck=[email-masked]
<mailto:shollenbeck=[email-masked]> >
Date: Tuesday, February 8, 2022 at 1:57 PM
To: [email-masked] <mailto:[email-masked]>  <[email-masked]
<mailto:[email-masked]> >
Subject: [EXTERNAL] Re: [regext] I-D Action:
draft-ietf-regext-rdap-openid-10.txt

CAUTION: This email came from outside your organization. Don?t trust emails,
links, or attachments from senders that seem suspicious or you are not
expecting.

> From: I-D-Announce <[email-masked]
<mailto:[email-masked]> > On Behalf Of
> [email-masked] <mailto:[email-masked]> 
> To: [email-masked] <mailto:[email-masked]> 
> Cc: [email-masked] <mailto:[email-masked]> 
> This draft is a work item of the Registration Protocols Extensions WG of
the
> IETF.

[SAH] Please review this, folks. It's been significantly modified since
version -09, replacing the token management queries with simpler login,
logout, and session queries. This puts the draft in a much better position
with respect to RDAP behaving like a web service, and it simplifies client
processing, too.

Scott

_______________________________________________
regext mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/regext
<https://secure-web.cisco.com/1JIxbOCMKQqXhfEiMgDTkDXixRGPaaQXTB7s7ED0banKPz
W9_e8PCvuZoSoExzMdIytk_BEEmfutPZ9LGTr0PLi5v230tO6NHDSJ71XuWYHlRai17-FlwwSPyn
RH2Ux2Yx3jSOaT54uopzx3hjBedfeoraZEprj6lbIHkl3P-ZhsMCIiXnI-a1Jtt_bMSreDxTkzHG
qeMKix6SMpyD_QLzH8RXXMoV-W6tQE--1mh3mSZ5uGre7XhxlYNR-Z53I_E/https%3A%2F%2Fww
w.ietf.org%2Fmailman%2Flistinfo%2Fregext>

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 9 Feb 2022 19:06:46 +0100

Hi Scott,

a first feedback is about the "notice" object used in the examples.

It seems to me that the values of the "description" member are not 
compliant with what is stated in section 4.3 of RFC 9083:

*an array of strings named "description" for the purposes of conveying 
any descriptive text*

As a general rule, I think we should not use jagged arrays. They are 
harmful for clients because they cannot be deserialized straightforwardly.

This is also one of the reasons why jCard is considered inefficient.

So I would opt for defining a new "session response" based on an 
unambiguous data model.

Best,

Mario

Il 08/02/2022 19:57, Hollenbeck, Scott ha scritto:
>> From: I-D-Announce<[email-masked]>  On Behalf Of
>> [email-masked]
>> To:[email-masked]
>> Cc:[email-masked]

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Feb 2022 20:05:03 +0000

From: regext <[email-masked]> On Behalf Of Mario Loffredo
Sent: Wednesday, February 9, 2022 1:07 PM
To: Hollenbeck, Scott <shollenbeck=[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Caution: 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.

Hi Scott,

It seems to me that the values of the "description" member are not compliant with what is stated in section 4.3 of RFC 9083:

an array of strings named "description" for the purposes of conveying any descriptive text

As a general rule, I think we should not use jagged arrays. They are harmful for clients because they cannot be deserialized straightforwardly.

So I would opt for defining a new "session response" based on an unambiguous data model.

[SAH] Thanks for catching that, Mario. What about something like this (might not be valid json…)?

     {

       "notices": {

         "title": "Login Result",

         "description": [

           "Login succeeded", "user.idp.example"

         ],

         "lang": "en-US"

       },

       "userInfo": {

         "claims": {

           "iss": "https://accounts.someprovider.com",

           "azp": "729559086898-onapsvnhf2og.apps.someprovider.com",

           "aud": "729559086898-onapsvnhf2og.apps.someprovider.com",

           "sub": "103892603076825016132",

           "email": "[email-masked]",

           "email_verified": true,

           "at_hash": "es5maY5y9jBAWCBMhLokAQ",

           "nonce": "dcb29f97c836726ddc074f76fbc21bfd",

           "name": "User Person",

           "picture": "https://lh3.someprovider.com/a-/AOh14=s96-c",

           "given_name": "User",

           "family_name": "Person",

           "locale": "en",

           "iat": 1644239971,

           "exp": 1644243571,

           "purpose": "domainNameControl",

           "dnt": false

         },

         "session": {

           "Expires in (seconds)": 3599

         }

       },

     }

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 10 Feb 2022 09:34:24 +0100

Hi Scott,

please find my comments below.

Il 09/02/2022 21:05, Hollenbeck, Scott ha scritto:
>
> *From:* regext <[email-masked]> *On Behalf Of *Mario Loffredo
> *Sent:* Wednesday, February 9, 2022 1:07 PM
> *To:* Hollenbeck, Scott <shollenbeck=[email-masked]>; 
> [email-masked]
> *Subject:* [EXTERNAL] Re: [regext] I-D Action: 
> *Caution:*This email originated from outside the organization. Do not 
> */[SAH] Thanks for catching that, Mario. What about something like 
> this (might not be valid json…)?/*
>
>      {
>
> "notices": {
>
> "title": "Login Result",
>
> "description": [
>
The property name "Expires in (seconds)" cannot be deserialized 
straightforwardly.

Another point: I wonder if we really need to return the claims to the 
End-User.  The only possible purpose coming in to my mind is that the 
End-User can check the claims and decide to logout or withdraw the 
session because he doesn't recognize himself in the claims. For example, 
an End-User willing to submit requests that shouldn't be logged by the 
server could check that the "dnt" claim is set to true. Right ?

If yes, I think that a text explaining why the claims are returned 
should be added. Maybe a point might be added to the list in section 
3.1.2 or text added to section 3.1.3.6 .

Anyway, the "claims" object as shown in your example contains some 
members that are included in the ID Token 
(https://openid.net/specs/openid-connect-core-1_0.html#IDToken) but 
missing in the UserInfo response 
(https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse) 
such as "iss", "nonce", and others. In my opinion, those members should 
be removed from the response because they are meaningless for the End-User.

In addtion, the resulting "claims" object would be more compliant with 
what is stated in section 3.1.3.6 .

    OpenID Connect specified a set of standard Claims in Section 5.1.
    Additional Claims for RDAP are described in Section 3.1.4.

Best,

Mario