** VO

   - VOs of VOs are possible
     - Note to JU: VO hierarchical need.  (And possibly overlapping
       at the physical layer. Also interested in meta-data about VOs.)

Resolved: Membership need not be agreed jointly by the VO and the
          member.

Resolved: VOs (or members thereof) can delegate authorization rights
          to parent VOs. Propagation of rights may be prohibited by
          members.

Note that membership may be contingent on agreement to certain policy
agreements.

   Comment: Have to also consider what happens when the VO changes
            some part of its policy. May need all members to agree
            before changes can be accepted.

Resolved: We will need additional artifacts so that VOs support a
          strong trust concept.

Resolved: It is NOT necessary to add functionality to the GSH naming
          scheme to support VOs.

   Comment: There is a desire to be sure that when you get a name it
            really refers to the 'right' thing (secure name). But we
            may be mixing authentication and identity. Also if you put
            a public key in name (so the name carries some proof) then
            key rollover (if your key is compromised) is tough.

Resolved: We do NOT want to factor a VO into its bag part (registry?)
          and the trust model. This will be done by the WG that takes
          this up.

Resolved: The VO MUST include: GSH plus a set of security bits to make
          the implementation of a membership authority possible.  The
          VO MAY contain other information. .