[OGSA-AUTHZ] checkpointing the discussion on VO attributes
David Chadwick
d.w.chadwick at kent.ac.uk
Wed Jan 30 10:43:59 CST 2008
Valerio Venturi wrote:
> On Tue, 2008-01-29 at 10:20 +0100, David Groep wrote:
> Sounds good. Another similar issue has been issued here an there,
> defining XACML attributes and obligation needed for authorization
> services. What about including that too? This is something that those
> implenting authorization services are facing, as you know, and community
> consensus would be very important.
> Also, deciding that may help in sorting out one of the main concern with
> the current authz decision spec, that is, having or not having attribute
> and obligation definition in the profile.
> If we can be sure to have those defined in a separate document to be
> released soon, may be it's ok to remove them from the current spec.
> DavidC, what do you think about that?
As I have said all along, I think defining attributes and obligations is
a long term project that will mature as more people start to use them. I
dont think a quick fix spec is the correct approach, because if it is
quick, it wont be complete, and if it is complete it cannot be quick.
Therefore the approach that I have been advocating is a two step one. A
quick first stab at a few core attributes and obligations (either in an
existing doc so that a charter change is not needed) or as a separate
doc (in which case a charter change or new WG is needed) - I dont
actually mind which approach is taken. But I dont support the creation
of a new WG, since this will only dilute the effort we have, and it is
likely to grow to include further topics (such as obligations :-) as one
sees fit. If one is concerned about the progress of the current set of
Authz documents it is because very few people are actually contributing
to them, and some that are working in the area do not wish to actively
contribute.
After the first quick fix has been published then a much longer term
project to produce a richer set can start. This longer term project must
have an active dynamic set of attributes and obligations that can be
added to as the need arises, rather like an IETF/IANA registration
authority for well known ports. So it might be a web page that publishes
this, rather than a paper document. It musn't be a static set, of that I
am sure (I have enough experience of LDAP schemas to know this)
regards
David
>
> For what concern (co)chairing, I'd like very much if you and Blair think
> it would help, but I need to check with my management. Given the unclear
> destiny of the project I've benn working on, I'm not sure I'll be
> working 100% on authorization starting from May. Until then, I'm
> available for bootstraping things.
>
> Valerio
>
>
>> Comments welcome!
>>
>> DavidG.
>>
>>
>>> Valerio
>>>
>>>
>>> On Mon, 2008-01-21 at 15:22 +0100, 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
>>
>
> --
> 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
*****************************************************************
More information about the ogsa-authz-wg
mailing list