Valerio Venturi wrote:
On Mon, 2008-01-21 at 15:52 +0100, Chad La Joie wrote:
Yes, when I made the comment about the VO needing an entity ID I was thinking that a VO would be represented by a distinct piece of software. Given my updated understanding that a single piece of software might represent multiple VOs, then yes, I think the VO attribute is needed. What does need an entity ID is the VO software system.
Thinking in VOMS terms, where service instances and VO have a one-to-one or many-to-one relationship, I liked the idea. But there's the need for having one-to-may relationships. If I understand correclty, Krzysztof were thinking about doing something like
<saml:Attribute ... FriendlyName="vo" <saml:AttributeValue xsi:type="xsd:string"> aVo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> anotherVo </saml:AttributeValue> </saml:Attribute>
Right.
If we go for that, on the line of the agreement on roles and groups, that a role scoped in a group must not be present if the group is not present , I guess the same must be done for groups. Groups hierarchically based in a VO must not be present is the vo is not present.
I think we agree, but I will rearticulate this to be sure: Attribute stating that a subject is a member of a group 'G', hierarchically based in a VO 'V', implies that the subject is a member of 'V'. I think that using the form 'must (not) be present' can be misleading as response containing only e.g. group-attributes (without vo-attributes) is perfectly valid if requester queried only for them. This topic brings question if we assume the same for 'subgroup hierarchically based in a group' case? For me the answer should be positive. However AFAIR in VOMS membership in a subgroup doesn't imply membership in its parent group, isn't it? Best regards, Krzysztof