I have contacted those who made comments on the SD spec. They were happy with the proposals agreed upon in Singapore with the exception of the vo-filter. I thought it was worth bringing this point to the list for people to think about. Once this is fixed I will edit the document as agreed.
In the main spec the context has an attribute:
! // name: UserVO
! // desc: the VO the context belongs to
! // mode: ReadWrite
! // type: String
! // value: -
! // note: - a typical example for a globus type context
! // would be "O=dutchgrid".
Here it is quite reasonable to call it UserVO as it is in the session context, however for service discovery as the API allows you to find out about services not available to your VO then UserVO is not the most natural name and I prefer to leave it as VO (contrary to what I agreed in Singapore).
We also need to be mappable on to GLUE. The GLUE 2.0 document says:
In the GLUE Information Model, the Virtual Organization can be realized by using the concept of UserDomain. If the VO has an internal structure, this can be represented by using different domains related to each other. A Virtual Organization (VO) comprises a set of individuals and/or institutions having direct access to computers, software, data, and other resources for collaborative problem-solving or other purposes. Resources utilized by a VO are expected to be accessible via network endpoints and constrained by defining utilization targets called shares. The VO can exhibit the internal structure in terms of groups of individuals, each of them being a UserDomain. UserDomains can be hierarchically structured. This structure can be represented via the "participates in" association.
Sylvain Reynaud has said:
I agree for equivalence between VO and group, but I still think that
filtering by group (or VO) is just an example of authorization
filtering. Indeed, authorization does not always only depend on group
(or VO) membership, even for grid deployments. For example,
authorization may also depend on role (e.g. in LCG, access to tier 1
sites should be restricted to role "production" instead of the entire
VO. See
http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_queues_with_access_restricted_to_a_FQAN),
or it may depend only on UserID (e.g. Globus gridmap file). Then, how
could we filter the services that are really accessible to the user?
Moreover, I think that infrastructures that do not want to make efforts
to match the SAGA Service Discovery specification should also be
accessible through this API.
However I think that going this way leads to an API that can no longer be considered to be simple. One can of course use the key value pairs to show groups and roles and any other authz information if it is wished - so I propose to leave it as it is with just VO. If it turns out that groups and roles really turn out to be useful as key values then we can add them in later as full SD attributes - but it is more troublesome to remove them later.
Comments please.
Steve