Since this model is also intended for deployments of the RSP at iDACs I would like to express some concerns even if I'm not a developer of RSP services, which was the main intention of this RFC. I hope you don't mind.
I fully understand the motivations of this proposal and appreciate the flexibility and control this model would provide to the developers of the RSP services. However, I would adventure to say that making the RSP a hermetic bubble would prevent users to analyse datasets coming from several instruments (and living outside the RSP) using the services provided by the RSP and I think that would be a missed opportunity.
CC-IN2P3 users are not only well identified (they must have their own account which they use for several services) but are more often than not involved in several scientific projects (e.g. Rubin and EUCLID, Rubin and ZTF, Rubin and HSC, etc.). Each of those projects has their own specific tools and conventions, but one thing in common is that the permissions set on the datasets those individual need (and has the right) to access to do their science are based on their user identity. Their user identity is also used for using the share of batch farm allocated to each of those projects. I don't see this pattern change in the near future, for all those projects at the same time, in a shared facility such as CC-IN2P3.
From my understanding of this proposal, if user A, member of Rubin and EUCLID, needs to do their analysis using data from both instruments, they could not do that using the RSP services since their identity within the RSP would be unrelated to their identity one outside the RSP, which they use for working on and accessing data from EUCLID. The same constraints would be present for accessing files in their $HOME, which would be different from their $HOME within the RSP environment.
This "split the world" approach to user identification and authentication would be a recipe for frustration for the users and for nightmares for the service provider that I am. I suspect other prospective iDACs could be impacted in the same way from such an implementation of the RSP. I hope there will be possible ways to not completely disconnect the RSP from the underlying infrastructure.