[rpp] Re: Session / registrar mapping

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

Ok, thanks Pawel, that makes sense.

To Jim's point, I don't want to start stuffing extra things into the
core protocol and expanding the scope, but I do wonder whether
automatically accepting the EPP model of an RPP user being exactly
equivalent to a registrar could limit what we can do with RPP. I'm
happy with Pawel's proposed wording for the requirements, I'll come
back later if I think there are specific places in the core design
where this could be an issue.

Thanks all!
Ruth

On Fri, 21 Nov 2025 at 13:14, Pawel Kowalik <[e-mail]> wrote:
>
> 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]