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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Feb 2022 16:55:58 +0000

From: Mario Loffredo <[email-masked]>
Sent: Thursday, February 10, 2022 3:34 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
Subject: [SUSPICIOUS MESSAGE] [EXTERNAL] [SPAM] 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,

please find my comments below.

Il 09/02/2022 21:05, Hollenbeck, Scott ha scritto:

From: regext  <mailto:[email-masked]> <[email-masked]> On 
Behalf Of Mario Loffredo
Sent: Wednesday, February 9, 2022 1:07 PM
To: Hollenbeck, Scott  <mailto:shollenbeck=[email-masked]> 
<shollenbeck=[email-masked]>; [email-masked] 
<mailto:[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,

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.

[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://secure-web.cisco.com/1SENSmpCLOpO4y0OpP-M2vHQx3yvVlXW-vEl55sYCFP5bzatUTw--UMcbNCxuhg5jzZ-oaV4jhVfYQCtLCyymm0m_wIWUMfJGFptWDIhlq8ei7szTfYOsPU761N5YZByLu8dFeUD2u12Jj7Mb2ucFYN5bizX7gF5alRPFPR5ouxz5TTcA7JaaW1IHzArKSlcpD0k6iW3iOcx2oCSBJSz9rV68rHz8HUefkBdeZXW2qiJvlLVcF3uh_88i7mD1WH7x4CoNzIhRbAXak-KoJiZJJSORMZM6_QK43p_Jf3eHF7SOO0uk4J1ozUP0-yZstyTu/https%3A%2F%2Faccounts.someprovider.com> 
"https://accounts.someprovider.com",

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

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

           "sub": "103892603076825016132",

           "email":  <mailto:[email-masked]> "[email-masked]",

           "email_verified": true,

           "at_hash": "es5maY5y9jBAWCBMhLokAQ",

           "nonce": "dcb29f97c836726ddc074f76fbc21bfd",

           "name": "User Person",

           "picture": 
<https://secure-web.cisco.com/1eYionJVViuLiOqC3iKMgO4oA7JH8lVjrCNERUxoASCNg54d1FxpMb9RJF3EdM1vvm3jjKgrzutnWX14VQJ7v8uB150AOItS7Elnhhk8tSbPnIK2CqWYKFW9LjalI1v1RmZ7cICe4dB6kU8Ni8ULS77DxUHPdtsLL-bgkI8Ho4HPdvELaf6DrO9lhkZgNvu9pQUjVqtfHvlM4al-zhsP-esr2EOa63wlPO3YfgGodTj9_lT1ckmxhTSPKtoC5EWK6jxxpp40hL06jnBIUr0Bz9__6464oOqgY-fBqlVwz8cElw-k20pWopmGKypUcnJKp/https%3A%2F%2Flh3.someprovider.com%2Fa-%2FAOh14%3Ds96-c> 
"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

         }

       },

     }

The property name "Expires in (seconds)" cannot be deserialized 
straightforwardly.

[SAH] OK, easy to fix. Let’s just call it “expiration”.

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 ?

[SAH] Right. Show the claims so the end user sees what’s being shared with the 
RDAP server, and let the user decide if they wish to proceed or not.

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 .

[SAH] OK.

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 
<https://secure-web.cisco.com/1GoYJ5n1W3Z7Yw7KJS_jAOaJk-DMmDU7sPqKugnABsmhnfsA55-F-d1SGDbLfBHo3nJctg6EFW6Z2gBfdFDd62WDiyJ_DIYdw5_2rmykqNisLQr2gKnSwJ8paOhogVyISl1BPtBE7MpfZvAE8dqSOg58tUNGUzqzDwZfztvnCzHWTMGOKtNUtbrg-uF8H6veC_yjuIe2rHrEIIcCUDc-v4678D5R6i_9KjHOWBKTNND_04kto1rknUUlVRt0E3DEN_L0VEyih3r3TJRQvxGVnhli3cv4_sqBaCOr4mnRdYHh9mfk5bfkjEGC5NNjOGnZV/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23IDToken> 
 ) but missing in the UserInfo response 
(https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse 
<https://secure-web.cisco.com/1kf5J1yEtF-2dHyP7ERRECWIDTxu5PUaGBQ3piYVrBKDaUXzt8z9GE02SJpqyq3zp26hZwGrdkMKc0_wkwVo-JZdxtvRD2SFT53sTG3ngj57PdymH9cgq7P5pWDDPtPuBKuyWum339IGmKkXsj7i4mpyXVhXfSurNVjx8lInMhnYm7EJcBUA7ACyJAZtVtuetI_bvtUSMA9vK-QLu7KTwDVZw8Gvcd2EjwtFrYtOF34Oo6giJSKWZHpOQNLxVQwOsFKevullt4D_7RNnMKG9eqV2u7gphjXagfZQnacMZZnu82s_Kxu6Mz73wjZCszM9O/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23UserInfoResponse> 
 ) 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.

[SAH] I temporarily included all the verified claims sent by the OP (which 
includes all the information from the UserInfoResponse) for now because I don’t 
know if we can really assess what an end user will understand or not. I think 
it’s better to return everything that we get from the OP so that we have full 
transparency, and the client can determine if/how to display that information 
to the user. Having said that, I’m open to the idea of returning the items 
from the UserInfo response instead of the complete set of verified claims as 
long as I also include the text that explains why the claims are returned as 
noted above and suggesting that the client determine which claims are exposed 
to 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.

[SAH] That’s true. OK, I’ll make the change and limit the return values to 
what’s returned in the UserInfo response. Thanks again for the feedback!

Best,

Mario

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 14 Feb 2022 08:04:57 +0100

Hi Scott,

here in the following some additional feedback:

1)  In the introductory sections, nothing is written about the fact that 
an RDAP server outsources authentication services to an OP  if the 
registry trusts that OP.

I think that this is a pre-condition to make a federation and for this 
reason, in my opinion, it's worth being mentioned somewhere at the 
beginning of the draft.

2) It seems from the text of section 3.1.3 that dynamic registration is 
the only method available  to register an RP. Instead, we all know that 
the most commonly used method to do that is manually through an 
out-of-band procedure. I think this alternative should also be mentioned 
to make section 3.1.3 consistent with the text in section 3.1.3.1 about 
the fact that an RDAP server can trust a limited number of OPs and 
out-of-band methods are used to implement the discovery process. If an 
RDAP server supports a limit number of OPs, it doesn't make sense that 
it is registered dynamically.

3) It seems from the draft content that the session expiring time is 
tied to the access token lifespan. Instead, in my experience with 
Keycloak, the session max idle time corresponds to the refresh token 
lifespan.

Honestly, don't know if this happens in other OPs, anyway, I would opt 
for letting the RDAP server choose the basis to calculate the session 
expiring time upon and in Section 4.2 I would omit the sentence "... to 
refresh the access token associated with the current session and ...".

In addition, in general, I would replace "token refresh" with "session 
refresh". After all, the endpoint that should be used for refreshing is 
called "session/refresh" and the final result to the End-User would be 
that the session lifetime is extended.

4) It doesn't make sense to me to return the claims in the response to 
the "session/refresh" query. Can they really change during the session?

5) If I understood well, a successful "session/refresh" query don't 
always result in resetting the session expiring time. How can the RDAP 
server decide to do that?

Best,

Mario

Il 11/02/2022 17:55, Hollenbeck, Scott ha scritto:
>
> *From:* Mario Loffredo <[email-masked]>
> *Sent:* Thursday, February 10, 2022 3:34 AM
> *To:* Hollenbeck, Scott <[email-masked]>; [email-masked]
> *Subject:* [SUSPICIOUS MESSAGE] [EXTERNAL] [SPAM] 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,
>
>     *From:* regext <[email-masked]>
>     <mailto:[email-masked]> *On Behalf Of *Mario Loffredo
>     *Sent:* Wednesday, February 9, 2022 1:07 PM
>     *To:* Hollenbeck, Scott
>     <shollenbeck=[email-masked]>
>     <mailto:shollenbeck=[email-masked]>; [email-masked]
>     *Subject:* [EXTERNAL] Re: [regext] I-D Action:
>     *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": [
>
>     "iss": "https://accounts.someprovider.com"
>     <https://secure-web.cisco.com/1SENSmpCLOpO4y0OpP-M2vHQx3yvVlXW-vEl55sYCFP5bzatUTw--UMcbNCxuhg5jzZ-oaV4jhVfYQCtLCyymm0m_wIWUMfJGFptWDIhlq8ei7szTfYOsPU761N5YZByLu8dFeUD2u12Jj7Mb2ucFYN5bizX7gF5alRPFPR5ouxz5TTcA7JaaW1IHzArKSlcpD0k6iW3iOcx2oCSBJSz9rV68rHz8HUefkBdeZXW2qiJvlLVcF3uh_88i7mD1WH7x4CoNzIhRbAXak-KoJiZJJSORMZM6_QK43p_Jf3eHF7SOO0uk4J1ozUP0-yZstyTu/https%3A%2F%2Faccounts.someprovider.com>,
>
>     "email": "[email-masked]" <mailto:[email-masked]>,
>
>     "email_verified": true,
>
>     "picture": "https://lh3.someprovider.com/a-/AOh14=s96-c"
>     <https://secure-web.cisco.com/1eYionJVViuLiOqC3iKMgO4oA7JH8lVjrCNERUxoASCNg54d1FxpMb9RJF3EdM1vvm3jjKgrzutnWX14VQJ7v8uB150AOItS7Elnhhk8tSbPnIK2CqWYKFW9LjalI1v1RmZ7cICe4dB6kU8Ni8ULS77DxUHPdtsLL-bgkI8Ho4HPdvELaf6DrO9lhkZgNvu9pQUjVqtfHvlM4al-zhsP-esr2EOa63wlPO3YfgGodTj9_lT1ckmxhTSPKtoC5EWK6jxxpp40hL06jnBIUr0Bz9__6464oOqgY-fBqlVwz8cElw-k20pWopmGKypUcnJKp/https%3A%2F%2Flh3.someprovider.com%2Fa-%2FAOh14%3Ds96-c>,
>
>     "given_name": "User",
>
>     "family_name": "Person",
>
>     "locale": "en",
>
>     "iat": 1644239971,
>
>     "exp": 1644243571,
>
> */[SAH] OK, easy to fix. Let’s just call it “expiration”./*
>
> 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 ?
>
> */[SAH] Right. Show the claims so the end user sees what’s being 
> shared with the RDAP server, and let the user decide if they wish to 
> proceed or not./*
>
> 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 .
>
> */[SAH] OK./*
>
> Anyway, the "claims" object as shown in your example contains some 
> members that are included in the ID Token 
> <https://secure-web.cisco.com/1GoYJ5n1W3Z7Yw7KJS_jAOaJk-DMmDU7sPqKugnABsmhnfsA55-F-d1SGDbLfBHo3nJctg6EFW6Z2gBfdFDd62WDiyJ_DIYdw5_2rmykqNisLQr2gKnSwJ8paOhogVyISl1BPtBE7MpfZvAE8dqSOg58tUNGUzqzDwZfztvnCzHWTMGOKtNUtbrg-uF8H6veC_yjuIe2rHrEIIcCUDc-v4678D5R6i_9KjHOWBKTNND_04kto1rknUUlVRt0E3DEN_L0VEyih3r3TJRQvxGVnhli3cv4_sqBaCOr4mnRdYHh9mfk5bfkjEGC5NNjOGnZV/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23IDToken>) 
> but missing in the UserInfo response 
> <https://secure-web.cisco.com/1kf5J1yEtF-2dHyP7ERRECWIDTxu5PUaGBQ3piYVrBKDaUXzt8z9GE02SJpqyq3zp26hZwGrdkMKc0_wkwVo-JZdxtvRD2SFT53sTG3ngj57PdymH9cgq7P5pWDDPtPuBKuyWum339IGmKkXsj7i4mpyXVhXfSurNVjx8lInMhnYm7EJcBUA7ACyJAZtVtuetI_bvtUSMA9vK-QLu7KTwDVZw8Gvcd2EjwtFrYtOF34Oo6giJSKWZHpOQNLxVQwOsFKevullt4D_7RNnMKG9eqV2u7gphjXagfZQnacMZZnu82s_Kxu6Mz73wjZCszM9O/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23UserInfoResponse>) 
> 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.
>
> */[SAH] I temporarily included all the verified claims sent by the OP 
> (which includes all the information from the UserInfoResponse) for now 
> because I don’t know if we can really assess what an end user will 
> understand or not. I think it’s better to return everything that we 
> get from the OP so that we have full transparency, and the client can 
> determine if/how to display that information to the user. Having said 
> that, I’m open to the idea of returning the items from the UserInfo 
> response instead of the complete set of verified claims as long as I 
> also include the text that explains why the claims are returned as 
> noted above and suggesting that the client determine which claims are 
> exposed to the end user./*
>
> In addtion, the resulting "claims" object would be more compliant with 
> what is stated in section 3.1.3.6 .
>
> */[SAH] That’s true. OK, I’ll make the change and limit the return 
> values to what’s returned in the UserInfo response. Thanks again for 
> the feedback!/*
>
> Best,
>
> Mario
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
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: Mon, 14 Feb 2022 13:44:25 +0000

From: Mario Loffredo <[email-masked]>
Sent: Monday, February 14, 2022 2:05 AM
To: Hollenbeck, Scott <[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,

1)  In the introductory sections, nothing is written about the fact that an RDAP server outsources authentication services to an OP  if the registry trusts that OP.

I think that this is a pre-condition to make a federation and for this reason, in my opinion, it's worth being mentioned somewhere at the beginning of the draft.

[SAH] OK, I’ll see what I can add.

2) It seems from the text of section 3.1.3 that dynamic registration is the only method available  to register an RP. Instead, we all know that the most commonly used method to do that is manually through an out-of-band procedure. I think this alternative should also be mentioned to make section 3.1.3 consistent with the text in section 3.1.3.1 about the fact that an RDAP server can trust a limited number of OPs and out-of-band methods are used to implement the discovery process. If an RDAP server supports a limit number of OPs, it doesn't make sense that it is registered dynamically.

[SAH] Agreed, I’ll add text to make it clear that out-of-band methods are both available and acceptable.

3) It seems from the draft content that the session expiring time is tied to the access token lifespan. Instead, in my experience with Keycloak, the session max idle time corresponds to the refresh token lifespan.

Honestly, don't know if this happens in other OPs, anyway, I would opt for letting the RDAP server choose the basis to calculate the session expiring time upon and in Section 4.2 I would omit the sentence "... to refresh the access token associated with the current session and ...".

[SAH] Agreed. The expiration value is only RECOMMENDED per the normative reference, so it really is up to the RDAP server to determine when things expire.

In addition, in general, I would replace "token refresh" with "session refresh". After all, the endpoint that should be used for refreshing is called "session/refresh" and the final result to the End-User would be that the session lifetime is extended.

[SAH] Agreed.

4) It doesn't make sense to me to return the claims in the response to the "session/refresh" query. Can they really change during the session?

[SAH] They can’t, but I think it’s a good idea to return them so that the client has an easy way to retrieve that information at any time without having to logout and then login again.

5) If I understood well, a successful "session/refresh" query don't always result in resetting the session expiring time. How can the RDAP server decide to do that?

[SAH] As noted above, it’s something that the RDAP server has to manage. I’d like to RECOMMEND and make it clear that the RDAP server SHOULD extend the duration of a session as part of processing a refresh, otherwise a refresh doesn’t do anything. Thanks again for the feedback!

Scott

---

From: Jasdip Singh <[email-masked]>
Date: Mon, 14 Feb 2022 15:33:56 +0000

Hello Scott,

I like the overall direction of this draft to help simplify things for RDAP clients and facilitate adoption, but wanted to share couple of observations:

1. There are 3 newly proposed RDAP path segments, starting with “login”, “session”, and “logout”. Looks like, for simplicity, we could coalesce them as “session/{start|refresh|end}”, with “login” becoming “session/start”, and “logout” “session/end”. “device” and “devicepoll” could be appended in the path as-n-when needed.

2. Wonder if we would be better-off defining a new RDAP object class called “session” instead of overloading the current definition of a notice? IIUC, per RFC 9083, “description” (in a notice object) is an array of strings for the purposes of conveying any descriptive text. Looks like returning “claims” and the session expiration info could use a new, more axiomatic structure instead. Further, this should help RDAP clients avoid parsing descriptive text (something not recommended) for the session semantics. Defining this new “session” object class should also correlate well with the proposed coalescing of the 3 new path segments into “session/…”.

Regards,
Jasdip

From: regext <[email-masked]> on behalf of "Hollenbeck, Scott" <shollenbeck=[email-masked]>
Date: Monday, February 14, 2022 at 8:44 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Hi Scott,

[SAH] Agreed.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 14 Feb 2022 17:11:54 +0000

From: Jasdip Singh <[email-masked]>
Sent: Monday, February 14, 2022 10:34 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Hello Scott,

[SAH] What do you all think of this suggestion? The draft currently has “login”, logout”, and “session” path segments. Should they be combined?

[SAH] Agreed, this is a good idea.

Regards,

Jasdip

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of "Hollenbeck, Scott" <shollenbeck=[email-masked]<mailto:shollenbeck=[email-masked]>>
Date: Monday, February 14, 2022 at 8:44 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

From: Mario Loffredo <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 14, 2022 2:05 AM
To: Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Hi Scott,

[SAH] Agreed.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 17 Feb 2022 13:24:33 +0000

From: regext <[email-masked]> On Behalf Of Hollenbeck, Scott
Sent: Monday, February 14, 2022 12:12 PM
To: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt

From: Jasdip Singh <[email-masked] <mailto:[email-masked]> >
Sent: Monday, February 14, 2022 10:34 AM
To: Hollenbeck, Scott <[email-masked] 
<mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: 
draft-ietf-regext-rdap-openid-10.txt

Hello Scott,

I like the overall direction of this draft to help simplify things for RDAP 
clients and facilitate adoption, but wanted to share couple of observations:

1. There are 3 newly proposed RDAP path segments, starting with “login”, 
“session”, and “logout”. Looks like, for simplicity, we could coalesce them as 
“session/{start|refresh|end}”, with “login” becoming “session/start”, and 
“logout” “session/end”. “device” and “devicepoll” could be appended in the 
path as-n-when needed.

[SAH] What do you all think of this suggestion? The draft currently has 
 “login”, logout”, and “session” path segments. Should they be combined?

[SAH] I’m going to make a suggestion in the absence of any feedback. I’d like 
to remove the session path segment and combine it with the login path segment 
such that the draft will describe the following path segments:

/login

/login/status

/login/refresh

/login/device

/login/devicepoll

/logout

This eliminates the session path segment and merges the functionality with the 
“easier to understand” login/logout semantics. Any issues?

Scott

---

From: Jasdip Singh <[email-masked]>
Date: Thu, 17 Feb 2022 14:59:08 +0000

Scott,

That simplifies. Thanks.

Jasdip

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thursday, February 17, 2022 at 8:24 AM
To: Jasdip Singh <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

From: Jasdip Singh <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 14, 2022 10:34 AM
To: Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Hello Scott,

[SAH] I’m going to make a suggestion in the absence of any feedback. I’d like to remove the session path segment and combine it with the login path segment such that the draft will describe the following path segments:

/login
/login/status
/login/refresh
/login/device
/login/devicepoll
/logout

This eliminates the session path segment and merges the functionality with the “easier to understand” login/logout semantics. Any issues?

Scott

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 17 Feb 2022 10:17:36 -0500

> Le 17 févr. 2022 à 08:24, Hollenbeck, Scott <shollenbeck=[email-masked]> a écrit :
> 
> From: Jasdip Singh <[email-masked] <mailto:[email-masked]>> 
> To: Hollenbeck, Scott <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> This eliminates the session path segment and merges the functionality with the “easier to understand” login/logout semantics.

I would prefer to have a single endpoint for the “sessions”, as current practice. How about:

/session/login
/session/status
/session/refresh
/session/device
/session/devicepoll
/session/logout

Regards, Marc.

> Any issues?

---

From: Jasdip Singh <[email-masked]>
Date: Thu, 17 Feb 2022 15:57:05 +0000

My comment below.

Jasdip

From: Marc Blanchet <[email-masked]>
Date: Thursday, February 17, 2022 at 10:17 AM
To: "Hollenbeck, Scott" <shollenbeck=[email-masked]>
Cc: Jasdip Singh <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

Le 17 févr. 2022 à 08:24, Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:shollenbeck=[email-masked]>> a écrit :

From: regext <[email-masked]<mailto:[email-masked]>> On Behalf Of Hollenbeck, Scott
Sent: Monday, February 14, 2022 12:12 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

Hello Scott,

/login
/login/status
/login/refresh
/login/device
/login/devicepoll
/logout

/session/login
/session/status
/session/refresh
/session/device
/session/devicepoll
/session/logout

[JS] Like this better if everyone agrees. :)

Regards, Marc.

Any issues?

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 17 Feb 2022 16:00:37 +0000

From: Jasdip Singh <[email-masked]>
Sent: Thursday, February 17, 2022 10:57 AM
To: Marc Blanchet <[email-masked]>; Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

My comment below.

Jasdip

From: Marc Blanchet <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 17, 2022 at 10:17 AM
To: "Hollenbeck, Scott" <shollenbeck=[email-masked]<mailto:shollenbeck=[email-masked]>>
Cc: Jasdip Singh <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt

   Hello Scott,

   /login

   /login/status

   /login/refresh

   /login/device

   /login/devicepoll

   /logout

   /session/login

   /session/status

   /session/refresh

   /session/device

   /session/devicepoll

   /session/logout

   [SAH] Works for me, too.

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 17 Feb 2022 18:37:27 +0100

Il 17/02/2022 17:00, Hollenbeck, Scott ha scritto:
>
> *From:* Jasdip Singh <[email-masked]>
> *Sent:* Thursday, February 17, 2022 10:57 AM
> *To:* Marc Blanchet <[email-masked]>; Hollenbeck, Scott 
> <[email-masked]>
> *Cc:* [email-masked]
> *From: *Marc Blanchet <[email-masked]>
> *Date: *Thursday, February 17, 2022 at 10:17 AM
> *To: *"Hollenbeck, Scott" <shollenbeck=[email-masked]>
> *Cc: *Jasdip Singh <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt
>
>     Le 17 févr. 2022 à 08:24, Hollenbeck, Scott
>     <shollenbeck=[email-masked]> a écrit :
>
>     *From:* regext <[email-masked]> *On Behalf Of
>     *Hollenbeck, Scott
>     *Sent:* Monday, February 14, 2022 12:12 PM
>     *To:* [email-masked]; [email-masked]
>     *From:* Jasdip Singh <[email-masked]>
>     *Sent:* Monday, February 14, 2022 10:34 AM
>     I like the overall direction of this draft to help simplify things
>     for RDAP clients and facilitate adoption, but wanted to share
>     couple of observations:
>
>     1. There are 3 newly proposed RDAP path segments, starting with
>     “login”, “session”, and “logout”. Looks like, for simplicity, we
>     could coalesce them as “session/{start|refresh|end}”, with “login”
>     becoming “session/start”, and “logout” “session/end”. “device” and
>     “devicepoll” could be appended in the path as-n-when needed.
>
>     */[SAH] What do you all think of this suggestion? The draft
>     currently has “login”, logout”, and “session” path segments.
>     Should they be combined?/*
>
>     */[SAH] I’m going to make a suggestion in the absence of any
>     feedback. I’d like to remove the session path segment and combine
>     it with the login path segment such that the draft will describe
>     the following path segments:/*
>
>     *//*
>
>     *//login/*
>
>     *//login/status/*
>
>     *//login/refresh/*
>
>     *//login/device/*
>
>     *//login/devicepoll/*
>
>     *//logout/*
>
>     *//*
>
>     */This eliminates the session path segment and merges the
>     functionality with the “easier to understand” login/logout
>     semantics. /*
>
> */[SAH] Works for me, too./*
>
/*Agreed.*/

/*Mario
*/

> *//*