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 <mailto:regext-boun...@ietf.org> <regext-boun...@ietf.org> On Behalf Of Mario Loffredo Sent: Wednesday, February 9, 2022 1:07 PM To: Hollenbeck, Scott <mailto:shollenbeck=40verisign....@dmarc.ietf.org> <shollenbeck=40verisign....@dmarc.ietf.org>; regext@ietf.org <mailto: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://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:u...@someprovider.com> "u...@someprovider.com", "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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
