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? 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@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@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@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@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@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

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

Valerio Venturi wrote:

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>

Right.

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.

I think we agree, but I will rearticulate this to be sure: Attribute stating that a subject is a member of a group 'G', hierarchically based in a VO 'V', implies that the subject is a member of 'V'. I think that using the form 'must (not) be present' can be misleading as response containing only e.g. group-attributes (without vo-attributes) is perfectly valid if requester queried only for them. This topic brings question if we assume the same for 'subgroup hierarchically based in a group' case? For me the answer should be positive. However AFAIR in VOMS membership in a subgroup doesn't imply membership in its parent group, isn't it? Best regards, Krzysztof

Hi Krzysztof, On Jan 21, 2008 6:15 PM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

Valerio Venturi wrote:

...

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 ':'.

You're correct. I was thinking there might be some benefit to specify groups as URNs, but there doesn't seem to be any justification in that.

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).

Why not use the naming and comparison rules of the SAML Basic Attribute? (See sections 8.1.2 and 8.1.2.1 of [SAML2Prof].) No need to reinvent the wheel here. Tom

On Jan 21, 2008 7:10 PM, Krzysztof Benedyczak <golbi@mat.uni.torun.pl> wrote:

...

...

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).

Why not use the naming and comparison rules of the SAML Basic Attribute? (See sections 8.1.2 and 8.1.2.1 of [SAML2Prof].) No need to reinvent the wheel here. In case of SAML attribute's name you are of course right. But I was thinking about SAML attribute's *value* (group's name in this case).

Right, I know. All I was suggesting is that the same naming and comparison rules could apply in the case of group names. The rules are well defined (in the XML Schema spec) so why not leverage them straightaway (like the SSTC did in the case of Basic Attribute). Tom

You can if you want. I have the other two docs to edit David Valerio Venturi wrote:

Ok, looks like we have agreements on most of the point. Who takes the pen? Blair, DavidG, what about the chances that this may become an OGF doc? If there are some, we'll go with the OGF doc template.

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@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@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@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@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@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 *****************************************************************

I have the pen on the Attribute Exchange Profile right now, so I'll pass on this one. Thanks, Tom On Jan 28, 2008 11:00 AM, Valerio Venturi <valerio.venturi@cnaf.infn.it> wrote:

Anyone else? Krzysztof, Tom, Chad?

Valerio

On Mon, 2008-01-28 at 14:33 +0100, David Chadwick wrote:

...

You can if you want. I have the other two docs to edit

David

Valerio Venturi wrote:

...

Ok, looks like we have agreements on most of the point. Who takes the pen? Blair, DavidG, what about the chances that this may become an OGF doc? If there are some, we'll go with the OGF doc template.

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@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@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

-- ogsa-authz-wg mailing list ogsa-authz-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

Hi Valerio, all, Valerio Venturi wrote:

Ok, looks like we have agreements on most of the point. Who takes the pen? Blair, DavidG, what about the chances that this may become an OGF doc? If there are some, we'll go with the OGF doc template.

This is certainly a document that is clearly in scope for OGF doc and on track for rapid progress: there has been extensive discussion, community consensus is forming well, and is very relevant and timely. As a process issue, Blair and I do propose that this be done in a 'quick' dedicated working group, instead of lumping it with the OGSA-AuthZ group for which it (1) would mean a change of charter and (2) which is already stuck with a lot of documents that need to be finished as well. And doing a quick dedicated WG for this really does not take that long: with the ideas at hand we can do a BoF in 2-3 weeks in Boston, supported by the email list for those that cannot physically be present, and get the working group chartered right away. With just this one deliverable, that will be quick and clean. Doing this during the Security Area meeting which is already scheduled also not not need any additional effort on behalf of the coordinators of the document. And, personally, I think Valerio as a (co)chair of the such group would make things along very well. It can also help reduce confusion in oGF as a whole as it does not necessarily have bear the OGSA label in the name of the group, and the scope of this document is wider anyway. Valerio, would you support this idea? Blair and I are very willing to help getting this started. 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@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@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

-- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

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@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@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@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@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

-- ogsa-authz-wg mailing list ogsa-authz-wg@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@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 *****************************************************************

Hi Valerio it seems like the preferred course of action by the ADs is for the OGSA-Authz group to publish its existing specs then close down, and another group be formed with a new charter to do longer term attribute, obligation and other (yet to be decided) stuff. Thats fine by me. regards David Valerio Venturi wrote:

Hi,

...

...

...

...

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.

You're totally right, a quick fix spec is not what we need. Having a new group working on that seems to me going in the direction of more thought, complete documents, which is what we all would prefer.

...

...

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 Honestly I've a mild opinion on that. Probably it would be cleaner to have separated docs, as someone in the WG suggested, but I don't have problems with having some attributes defined in the authz decision request spec, and definitely this is not a showstopper.

...

...

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 I understood that the OGSA AuthZ WG is going to finish its work shortly after next OGF, or at least continuining at a minimum level, having the chartered docs in public comments. So I thought there wouldn't have been a big overlapping between the two WGs. Am I wrong? I implicitly suggested a change to the charter to include the attribute doc in my first mail, and my impression from talking with DavidG and Blair in the last momths is that they don't fell like changing the WG charter. Probably a clarification from the area directors on that is needed, since this is also related on how they see the future of the security area.

...

...

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.

I see your point, and I share your disappointment. But we cannot go chasing people and force them to commit. It's their choice, and either they're not interested in standards or they think it wasn't worth committing. As a condition for starting a new WG, we must have a real interest from the community. This means both time to commit, and implementation experience to share.

...

...

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)

Sounds good. I see you're the first to have ideas and attention in this topics. I think those things are worth a community effort, I don't mind what the name of the group is going to be.

Valerio

-- ***************************************************************** 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@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 *****************************************************************

Hi all, Blair Dillaway wrote:

Hi All,

What David stated is essentially correct. It is really no more effort to charter a new group than to re-charter an existing group with new deliverables. The bar is the same and it is preferred this group wrap-up the chartered deliverables before we start on new work.

Ok, so we'll consider DavidG's proposal later on. Not being chartered, the attribute doc would be an internal document. Given that, would you consider using OGF namespaces for our attribute Name url not correct? Valerio