Hi Scott,
please find my comments below.
Il 09/02/2022 21:05, Hollenbeck, Scott ha scritto:
*From:* regext <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>;
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";,
"azp": "729559086898-onapsvnhf2og.apps.someprovider.com",
"aud": "729559086898-onapsvnhf2og.apps.someprovider.com",
"sub": "103892603076825016132",
"email": "u...@someprovider.com",
"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
}
},
}
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
_______________________________________________
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
