Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt
Hi Scott,
please find my comments below.
Il 09/02/2022 21:05, Hollenbeck, Scott ha scritto:
*From:* regext *On Behalf Of *Mario Loffredo
*Sent:* Wednesday, February 9, 2022 1:07 PM
*To:* Hollenbeck, Scott ;
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
[regext] I-D Action: draft-ietf-regext-rdap-reverse-search-09.txt
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 : Registration Data Access Protocol (RDAP) Reverse search capabilities Authors : Mario Loffredo Maurizio Martinelli Filename: draft-ietf-regext-rdap-reverse-search-09.txt Pages : 12 Date: 2022-02-10 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities to find the list of domains related to a set of entities matching a given search pattern. In the RDAP context, an entity can be associated with any defined object class. Moreover, other relationships between object classes exist and might be used for providing a reverse search capability. Therefore, a reverse search can be applied to other use cases than the classic domain-entity scenario. This document describes RDAP query extensions that allow servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case but with a special focus on its privacy implications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-reverse-search-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] Fwd: New Version Notification for draft-ietf-regext-rdap-reverse-search-09.txt
Hi all, this version addresses the feedback provided by Tom and Jasdip. Thanks a lot Tom and Jasdip for your collaboration and support in making the document more comprehensive. The authors think that the doc is ready for the WGLC. Best, Mario Messaggio Inoltrato Oggetto: New Version Notification for draft-ietf-regext-rdap-reverse-search-09.txt Data: Thu, 10 Feb 2022 01:48:05 -0800 Mittente: internet-dra...@ietf.org A: Mario Loffredo , Maurizio Martinelli A new version of I-D, draft-ietf-regext-rdap-reverse-search-09.txt has been successfully submitted by Mario Loffredo and posted to the IETF repository. Name: draft-ietf-regext-rdap-reverse-search Revision: 09 Title: Registration Data Access Protocol (RDAP) Reverse search capabilities Document date: 2022-02-10 Group: regext Pages: 12 URL: https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-09.txt Status: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-reverse-search/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-reverse-search Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-rdap-reverse-search-09 Abstract: The Registration Data Access Protocol (RDAP) does not include query capabilities to find the list of domains related to a set of entities matching a given search pattern. In the RDAP context, an entity can be associated with any defined object class. Moreover, other relationships between object classes exist and might be used for providing a reverse search capability. Therefore, a reverse search can be applied to other use cases than the classic domain-entity scenario. This document describes RDAP query extensions that allow servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case but with a special focus on its privacy implications. The IETF Secretariat ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
