[rpp] Re: Session / registrar mapping

[Ruth Trevor-Allen <[e-mail]>]

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]