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