[rpp] Re: Session / registrar mapping

["Gould, James" <[e-mail]>]

I didn't interpret the request as applying to supporting the internal use of RPP for registry users that can have elevated privileges and impersonation capabilities.  I can see leveraging RPP internally and externally, where for internal purposes there is a need for registry user access with elevated privileges and impersonation capabilities.  Supporting the use of RPP for internal registry operations will expand the scope, where you may want to consider it in the design, but create an extension to support it later.  Is there was way to identify core functionality in the requirements along with future functionality for extensions that need to be considered during the design, since it would be best to prioritize the core functionality and incrementally add future features via extensions?      

Thanks,

-- 

JG 



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 11/21/25, 4:47 AM, "Pawel Kowalik" <kowalik=[e-mail] <mailto:[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] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>