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 <mario.loffr...@iit.cnr.it>
*Sent:* Thursday, February 10, 2022 3:34 AM
*To:* Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org
*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 <regext-boun...@ietf.org>
<mailto:regext-boun...@ietf.org> *On Behalf Of *Mario Loffredo
*Sent:* Wednesday, February 9, 2022 1:07 PM
*To:* Hollenbeck, Scott
<shollenbeck=40verisign....@dmarc.ietf.org>
<mailto:shollenbeck=40verisign....@dmarc.ietf.org>; regext@ietf.org
*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://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>,
"azp": "729559086898-onapsvnhf2og.apps.someprovider.com",
"aud": "729559086898-onapsvnhf2og.apps.someprovider.com",
"sub": "103892603076825016132",
"email": "u...@someprovider.com" <mailto:u...@someprovider.com>,
"email_verified": true,
"at_hash": "es5maY5y9jBAWCBMhLokAQ",
"nonce": "dcb29f97c836726ddc074f76fbc21bfd",
"name": "User Person",
"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,
"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
_______________________________________________
regext mailing list
regext@ietf.org
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
