Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-19.txt

[Pawel Kowalik <[e-mail]>]

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