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@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. I'd vote for the 2nd version, because of the arguments put by Valerio
Hello, Valerio Venturi wrote: previously: eduPersonScopedAffiliation was generally designed to serve education purposes and it can be misleading here.
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.
Please excuse me if I'll be totally wrong here. By any mean I'm not Grouper (or Signet) expert. From what I recall, in Grouper groups are expressed as [grp1]:[subgrp2]:..., and stems as it was proposed: stem1:stem2:... Anyway Grouper doesn't publish this information directly by means of SAML but indirectly, e.g. through LDAP using ldappc and then via Shib IdP. If I'm right here then the ':' instead of '/' as delimiter gives as little advantage and we can stick to quite popular and for me more intuitive VOMS syntax. If I'm wrong then probably we should change to ':'. In any case we must clearly define syntax of a group name (e.g. currently our service does allow for ':' in it) and comparison rules (as case sensitiveness). Regards, Krzysztof