[OGSA-AUTHZ] checkpointing the discussion on VO attributes

[Valerio Venturi]

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>

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.

Valerio



> Valerio Venturi wrote:
> > Hi,
> > I'll try to checkpoint the discussion had so far.
> > 
> > As Krzysztof is planning to serve more than one VO with the same
> > service, we cannot have a one to one relationship between entityIDs and
> > VOs, this imply the need of having a VO attribute. Which was also more
> > or less David's concern, an authority being able to assert whatever it
> > wants. If we go wiht this, the VO attribute stays.
> > We have two proposal so far. Tom suggested to use the MACE-Dir
> > eduPersonScopedAffiliation attribute
> > 
> > <saml:Attribute
> >   xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
> >   xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP"
> >   xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"
> >   ldapprof:Encoding="LDAP"
> >   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> >   Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9"
> >   FriendlyName="eduPersonScopedAffiliation">
> >   <saml:AttributeValue        
> >     xsi:type="xs:string">member at voName
> >   </saml:AttributeValue>
> > </saml:Attribute>
> > 
> > while in our first draft Krzysztof and I suggested the use of a specific
> > 
> > <saml:Attribute 
> >   xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
> >   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> >   Name="uri_to_define"
> >   FriendlyName="vo"
> >   xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string">
> >   <saml:AttributeValue xsi:type="xsd:string">
> >     voName 
> >   </saml:AttributeValue>
> > </saml:Attribute>
> > 
> > Let's try to agree on one.
> > 
> > There were concerns about Tom's proposal to use Grouper to express
> > groups, specifically about the contents being an URN. Anyway, the
> > specification doesn't mandate them to be URN, it recommends to use URIs
> > is uniqueness is to eb achieved.
> > 
> > Other concerns with using this?
> > 
> > Still we have no suggestions for expressing roles, apart from the
> > initial (but I have made the group syntax homogeneous with the above)
> > 
> > <saml:Attribute
> >   xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
> >   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> >   Name="uri_to_define"
> >   FriendlyName="role"
> >   xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string">
> >   <saml:AttributeValue xsi:type="xsd:string">
> >     VO-Admin at vo
> >   </saml:AttributeValue>
> >   <saml:AttributeValue xsi:type="xsd:string">
> >     SoftwareManager at vo:group:subgroup
> >   </saml:AttributeValue>
> > </saml:Attribute>
> > 
> > that seems to receive more favor than the one with the scope attributes.
> > 
> > What problems can you see with that?
> > 
> > Valerio
> > 
> > 
> > 
> > 
> > 
> > --
> >   ogsa-authz-wg mailing list
> >   ogsa-authz-wg at ogf.org
> >   http://www.ogf.org/mailman/listinfo/ogsa-authz-wg
>