[regext] Entity role in reverse search

[Mario Loffredo]

Hi folks,

this is for asking the WG for an opinion about what is the best way to 
represent the entity role in the reverse search based on the 
x-entity relationship (where x is any RDAP object including the 
"entities" member).


According to the current version of reverse search draft, the role can 
be represented as a path segment (e.g.: 
/domains/reverse/registrant?fn=yy) whereas the value"entity" is used 
for an unspecified role (e.g.: /domains/reverse/entity?fn=yy). I try 
to condense in the following the reasons behind that:


1) In a reverse search based on such a relationship, the role is usually 
specified (I mean normally one wants to know all the domains of a 
registrant)


2) I worked around the problem of how the presence of the "role" query 
parameter could be compliant with RFC9082: should it be considered as a 
part of the search pattern? or should it be considered as a metadata 
parameter (like sort, count, cursor, which makes sense only if joined 
with a search pattern) ?


3) It is well known that endpoints are protected instead of query 
parameters. Specifying the role as a path segment allows an RDAP 
operator to make access control decisions on a per role basis.


Jasdip e Tom, who are going to implement the reverse search for RIRs, 
have raised to me the objection that the role might anyway be specified 
as a query parameter (e.g.: 
/domains/reverse/entity?fn=yy&role=registrant).


Provided that, at the application level, it doesn't make a lot of 
difference if the role is passed as a path segment or a query parameter, 
we need to reach a consensus on this point definitively.


I list the possible alternatives below:

- to represent the role only as a path segment (as is now);

- to represent the role only as a query parameter;

- to require the RDAP servers to process both

- other


Your feedback would be very appreciated.

Best,

Mario

P.S. Jasdip e Tom please add your considerations if I missed something.


--
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

Re: [regext] id_token parameter usage in rdap-openid

[Tom Harrison]

Hi Mario,

On Thu, Nov 11, 2021 at 11:51:13AM +0100, Mario Loffredo wrote:
> I open a separate discussion about the usage of the id_token parameter as
> defined in the rdap-openid document.
> 
> The document states in section 5.2 that the id_token MUST be passed in the
> query string.
> 
> IMO, there are some drawbacks coming from it:
> 
> - I intended that the purpose of this parameter is enabling server operators
> to make fine-grained access control decisions based on the claims about the
> authenticated end-user. However, the same claims can be obtained by
> accessing  the standard OIDC /userinfo  endpoint
> (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) using the
> Access Token. Only the server operators willing to refine their access
> control based on claims would eventually make use of such OIDC feature. Note
> also that the /userinfo endpoint returns a JSON response that is much easier
> to process than a JWT. Finally note that access control is normally based on
> user roles that can be stored in the Access Token.
> 
> - removing the id_token parameter would save server operators to check and
> signal possible inconsistencies between the id_token and the access_token;
> 
> - stripping the id_token would significantly shorten the query string and,
> consequently, provide benefits to all the players. End-users would deal with
> leaner queries, clients could save memory, servers' logs would be less
> cumbersome and more readable;
> 
> - a JWT can be decrypted and the id_token may potentially include many PIIs.
> It isn't recommended to send PIIs as parameters of a query string even when
> the request is issued over an SSL connection.
> 
> The only advantage I found is that it would save server operators from
> querying the /userinfo endpoint each time the required claims are needed.
> 
> If so, I think that the issues outweigh the benefits and I would opt for its
> removal.

I'm not sure that it's possible to remove the ID token parameter from
the document, at least as it's currently written.  If no ID token is
provided, then the RDAP server will have only an access token to work
with, and the RDAP server must treat that token as opaque, since it's
a relying party (only the resource server can interrogate the access
token).  If all that the RDAP server gets is an opaque access token,
then it won't know which authorization server to contact in order to
verify that access token, so it won't be able to verify that the user
is authorized.

-Tom

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext