This is a page for comments on the VODefinition work. Please log in and add your own, or email MarkNorman. Thanks!

Andrew Martin (Oxford) via email

• when cross-institution projects get funded, legal ownership of the resources is allocated to those individaul institutions. But they are expected to share those resources across the project as a whole. So some people see that as a VO. Almost by definition, a VO can't own any resources, but in this context it comes close.
• likewise with projects that get given a particular kind of access to a third party resource: HPC(x), for example. The resource belongs to someone else. The time on it belongs to a particular real organisation. But the ability to access it might be shared by the VO.
• some people use the term to refer to a well-defined collaboration, with legal agreements in place among the parties. That's not really a VO, is it; it's more of an RO (real organisation). But is there a spectrum? A pure RO is established at law, can own property, be sued, etc. A pure VO is just an attribute service, perhaps. Or perhaps being a VO implies having some kind of agreement, too. But I don't like that so much --- it seems to compromise the purity of the idea, and make it heavier. But you can't issue attributes without some kind of policy for who gets them. So a VO must have a policy. Or must it?
• do the members of, say, the Grid and Shib mailing list constitute a VO? And if so, why? or why not? They don't typically have any funding in common; they have implicity agreed to share some ideas, however.

David Wallom (Oxford) verbal

A VO should just be a list. Where you have role attributes combining with general membership these form (sub) VOs themselves, but it isn't helpful to think of hierarchies of VOS. Therefore, they are new VOs.

• For example - using the previous International Ecology Society, a service could be available to IES full members, but not to associate members. You could think of one VO (IES member) but having some attributes (e.g. status: full_memb, assoc_memb) or you could think of these as two or more VOs (e.g. IES_full_memb and IES_assoc_memb).

2006-03-08 15:12:43].

MN follow-up

This would work, but only if we assume that the VO is in full control of the authorisation process for a particular service. Whereas a VO may often (or even usually) be in control, I don't think that we can assume this will always be the case.

• e.g. The IES has provided some sort of access to its membership list to service A (which also needs to know status information). If another service is started up independently of service A (let's call this service B ) that says "that's all the information I need to perform my authorisation decision too!", then we've got one list (plus attributes) serving two services.

I think that it's better to think of the service (or resource/site) being responsible for authorisation and the VO providing information for the decision to be made. (Even when the VO is in the driving seat, it's best to approach it this way, as it covers all cases, not just a sub-set). Maybe...

-- MarkNorman 2006-03-08 15:12:43

See Nate Klingenstein's wiki thoughts on VOs

At https://authdev.it.ohio-state.edu/twiki/bin/view/Main/VirtualOrganizations

A small excerpt:

• "...a VO:

  1. Relies on principals defined and authenticated by organizations;

  2. Creates and manages additional attributes about these principals that aren't suited for enterprise directories or are more appropriately asserted by the VO;

  3. Asserts these attributes about these people to specific applications and services, possibly in addition to attributes asserted by the original O's, in a tight trust framework. "

Nate sent this to the GGF shibgrid-bof mailing list on 8 March 06.

Back to the VODefinition page.