[rpp] Re: Session / registrar mapping

[Pawel Kowalik <[e-mail]>]

Hi Ruth,

This is what I mean with impersonation, without going deeper on how it would be realised.

Viele Grüße / Kind regards
Pawel Kowalik 

> On 21. Nov 2025, at 12:36, Ruth Trevor-Allen <[e-mail]> wrote:
> 
> Thanks Pawel, that looks good. We may also want to consider adding a
> way of specifying the registrar ID on operations where it can't be
> inferred, such as create?
> 
>> On Fri, 21 Nov 2025 at 09:46, Pawel Kowalik <[e-mail]> wrote:
>> 
>> Hi Ruth,
>> 
>> I think this is a very valid use case and covering internal usage by
>> registry was one of the added values of RPP.
>> This is something we are indeed missing in the requirements.
>> 
>> Proposal (in the Security section):
>> 
>> R9.x: RPP MUST support authorisation of registry operator power client
>> or user, being able to either impersonate any of the clients of the
>> registry, or act on behalf of registry with elevated access to
>> provisioning objects of all registry clients as well as operations
>> beyond of what is available to regular clients.
>> 
>> Would it cover this use case?
>> 
>> Kind Regards,
>> 
>> Pawel
>> 
>>> On 20.11.25 14:59, Ruth Trevor-Allen wrote:
>>> Hi all,
>>> 
>>> I've been working on a prototype RPP implementation for use with web
>>> apps, and something I'd like us to be able to support is use cases
>>> where a user is not necessarily exactly equivalent to a registrar. For
>>> example, they might be a superuser with access to carry out operations
>>> but no specific registrar ID, or an admin contact at multiple
>>> registrars with a single login to a web app which maps to multiple EPP
>>> logins. In order to offer a seamless experience to these users, it
>>> would be nice to be able to specify a registrar ID when carrying out
>>> operations where one is needed (for example domain: create), but it
>>> would also be nice not to have to identify the registrar for
>>> operations where it doesn't matter or can be inferred.
>>> 
>>> In particular, using EPP as a backend for apps like these, domain:
>>> check is an example of an operation where the actual registrar ID
>>> doesn't normally matter as long as the user has access to the TLD in
>>> general, and having to identify the appropriate user in order to
>>> submit the request can be undesirable overhead.
>>> 
>>> I don't know if this has implications for RPP design but wanted to
>>> flag it - is anyone else having these issues?
>>> 
>>> Thanks,
>>> Ruth
>>> 
>>> _______________________________________________
>>> rpp mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> rpp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]