> Not the CoI, unless this is going to perform some access control on users who are allowed to 
> access it. Rather it will be the resource admin that will be applying the access control rules.

Sorry, I should have been clearer. In this context, the COI does not refer to the trust router/portal concept, but the actual community of interest, i.e. the group of organisations/people who intend to run the service that the trust-router COI is designated for. Perhaps for this I should replace COI or community of interest with "group".

> if this is a COI portal, yes it will help, but even then it wont be providing fine grained 
> access to different users. This will only be done by the resource owner.

In your case, you have *someone* who administers the VO, right? That *someone* has been elected/chosen/arm-wrestled/contracted/volunteered from within your group to administer the VO, correct? So, that *someone* administers an attribute authority, or a portal, or an app users run on their laptop, or whichever way that your group chose to do it in a way that it is easy for users to use. It is after all there to serve your group who are in this VO.

So your users, who are part of a VO, could perhaps log into the VO portal, choose the resource they wish to log on to, authenticate themselves to their home organisation, and get a pretty little ID back that they can submit to the administrator of the resource (or could even be done automatically on their behalf). This is what webapps or phone apps are designed to do. :-)

But again, this is an implementation detail that is up to your group to decide. 

> Maybe we are talking at cross purposes here. I am thinking about how to set fine grained access controls for 
> users of resources, maybe based on the role of the user, or the user's ID, but it must be able to distinguish 
> between individual users in order to give them individual rights.

That would again be an implementation detail up to *you* and your group. So if you at the Uni Kent, someone at Uni Murcia and someone at CSC in Finland sit down and say "we want our SAML assertions to contain those specifics", then it is up to you to decide and implement this. A straight-forward attribute authority comes to mind, or a set number of rules that you expect all the sites in your group to implement at their appropriate IdPs and RPs 

The broader Moonshot system is not (and should not be) designed for such granularity. Its granularity stops at the service level, i.e. at the IdP and RP level because all it guarantees is the level of trust amongst the services in the trust router COI.

Stefan 

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238