[OGSA-AUTHZ] VO SAML Attribute Profile

[Krzysztof Benedyczak]

Hello,

After a bit of investigation of URI encoding I've run into some issues 
that, I think, need more discussion.

Some of them occurred after evaluating a simple use-case, which is:

let's consider a XACML policy which grants access for all entities who 
possess a 'role' attribute with a value 'Admin' in a scope of vo/group: 
'SomeVO/Staff'.

I believe that such a simple use case should be also simple to express, 
implement etc.


1) I assume that an attribute 'X' with value 'V' in scope of 'S1/S2/S3' 
should be expressed like this:
<saml:Attribute
   xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML"
   xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#anyURI"
   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
   Name="X"
   FriendlyName="friendly X">
  <saml:AttributeValue xsi:type="xsd:anyURI"
	>group://voservice/S1/S2/S3#V</saml:AttributeValue>
</saml:Attribute>

I wrote it because it isn't exactly as in Tom's proposal (so is it ok?). 
And also another issue: XACML DataType. As I understand the topic about 
the legacy/trivial/dummy software the problem is with values not being a 
simple string. Will it be OK for this software when it will see xsd:anyURI?


2) URI equivalence test in XACML is simple codepoint-by-codepoint (or 
UnicodeChar-by-UnicodeChar). Provided that, we come into a nightmare of 
infinite number of representations of the *same* scope+value pair:
  -) The VO service URI as part of SAML attribute value will complicate 
things a lot. Examples:
     *) group://serivice.org/services/foo - is it VO 'foo' of VOservice 
service.org/services OR group 'foo' of VO 'services' of VOservice 
'service.org'?
     *) when XACML policy requires 'group:///vo/group#Admin' and PDP 
receives 'group://VOservice.org/vo/group#Admin' then comparison will fail.
  -) shall we enforce an URI normalization for the 'group:' URIs? For 
possible examples of it see http://tools.ietf.org/html/rfc3986#section-6.2

I think that we can take two approaches. Either resign from putting 
voservice's URI as part of 'group:' URI at all - then it won't be 
globally unique but most of the problems will disappear. Or enforce 
voservice's URI to be put in 'group:' URI and define a canonical form. 
It will add uniques but at cost of complicated profile and implementation.

In favor of the first solution there is one more point - global 
uniqueness wasn't considered in our previous proposal (so at least we 
can live without it).


3) Having 'group:' URIs what about earlier 'VO' and 'group' SAML 
attributes (defined in the initial version of draft)? I think we should 
merge them into one attribute proposed by Tom: 'isMemberOf', with group 
URI syntax as a value. It will be enough to express both VO and group. 
'isMemberOf' attribute's namespace would be VO profile-specific.


Best regards,
Krzysztof