[rpp] Re: Session / registrar mapping

[Maarten Wullink <[e-mail]>]

how about this text proposal, i slightly tweaked Pawels proposed text.


RPP MUST allow the registry operator to impersonate or to act on behalf of, any of the registry system accounts.
This includes having elevated access for provisioning objects, performing normal operations and as well as operations not available to regular clients.



Best,

Maarten



> Op 25 nov 2025, om 11:08 heeft Ruth Trevor-Allen <[e-mail]> het volgende geschreven:
> 
> 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]
> 
> _______________________________________________
> rpp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]