[OGSA-AUTHZ] checkpointing the discussion on VO attributes

David Chadwick d.w.chadwick at kent.ac.uk
Mon Jan 21 09:52:47 CST 2008


Hi Valerio

Valerio Venturi wrote:
> On Mon, 2008-01-21 at 14:48 +0000, David Chadwick wrote:
>> Hi Valerio
>>
>> concerning the VO attribute I am not strongly for or against either 
>> approach, so I will sit on the fence on this one. (But I am strongly in 
>> favour of choosing one of them).
> 
> I agree, we'll choose one.
> 
>> Concerning the role attribute, I would strongly prefer the friendly name 
>> to be VOMSrole rather than role, since the syntax and semantics are VOMS 
>> specific creations. Role is already a standard attribute in X.509 and is 
>> a different syntax to your syntax. In PERMIS, we have defined the 
>> PermisRole attribute which does not have the same syntax as yours or 
>> X.509 (ours is just a string, any old string) and since it is different 
>> from the role attribute which is standardised in X.509 we did not call 
>> it simply role.
> 
> Ok for the name. But what about the syntax? Do you like the @ for
> scoping?

Its your call. To my mind this is a VOMS specific issue and not a grid 
generic issue. We have not had a reason or user requirement to do this 
in PERMIS.

regards

David

> 
> Valerio
> 
>> regards
>>
>> David
>>
>>
>> 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
>>>
>> -- 
>>
>> *****************************************************************
>> David W. Chadwick, BSc PhD
>> Professor of Information Systems Security
>> The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
>> Skype Name: davidwchadwick
>> Tel: +44 1227 82 3221
>> Fax +44 1227 762 811
>> Mobile: +44 77 96 44 7184
>> Email: D.W.Chadwick at kent.ac.uk
>> Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
>> Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
>> Entrust key validation string: MLJ9-DU5T-HV8J
>> PGP Key ID is 0xBC238DE5
>>
>> *****************************************************************
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************


More information about the ogsa-authz-wg mailing list