Hi Scott,
Feedback below.
Am 06.12.22 um 15:23 schrieb Hollenbeck, Scott:
Thanks for the feedback. More below...
- we discussed that we do not care that much about remote OPs, however the
issue of access_token coming from an unknown OP remains. My proposal for a
simple solution would be just to require a query parameter "OP Issuer
Identifier" with each RDAP query for non-default OP server. This would be an
add to 6.2
[SAH] The document already includes the "farv1_iss" query parameter that's
used with a login query. It can be used in this context as needed. Are you
suggesting that the document should include support for a client sending a
"farv1_iss" query parameter with a (for example) domain query such that the
RDAP server will start a session-oriented login process prior to processing
the domain query? If not that, are you suggesting that receipt of a
"farv1_iss" query parameter will simply identify the issuer to the RDAP server
so that the RDAP server can attempt to process the access token received from
a token-oriented client? The latter makes more sense to me.
[PK] Yes, absolutely I meant the latter.
I see value in remote OPs. In the ICANN registry/registrar world, I fully
believe there is room for entities like law enforcement, security researchers,
intellectual property interests, and similar "communities of interest" to
deploy and operate identity providers for their members. That model scales
better than every registry/registrar RDAP server operator having to operator
their own OP and issue credentials to every person who wants access to their
service. If they do that, they might as well just issue user names and
passwords for use with HTTP Basic authentication.
[PK] Yes I see that too, therefore with "farv1_iss" it would be working.
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
