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?
By "legacy software," I think you mean some SAML V1.1 implementations? Well, the XACML Attribute Profile is new in SAML V2.0, so I don't think backwards compatibility is an issue.
That said, I wonder if it would be better to specify string rather than anyURI. (Thinking out loud here.) I mean the software which was mentioned in other emails e.g. the last
Tom Scavo wrote: paragraph of the first Chad's post in this thread. This software was the reason for not using (generally much cleaner, I think) an additional SAML attribute value's XML attribute to encode a scope (point 4.2 of initial proposal).
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: After reading your answer I think we have some little misunderstanding here. So one general comment here and one more detailed later inline.
I'm perfectly aware that SAML assertion has Issuer id, and - as a whole assertion - will be globally unique. I initially thought that you wish to put literally the Issuer id once again in group: URI. Now as you see the first part of URI as: group://SCOPE/vo_name/group_name/subgroup_name#role and SCOPE is defined for exclusively for the Issuer - every Issuer can have many of them, and those must be unique in the way that never two issuers use the same SCOPE. Do I understand it correctly now? If so two questions: - do we really need the possibility to define multiple SCOPEs for one IdP? For me one such SCOPE per Issuer would be perfectly enough - all other differentiation can be at VO level. - do we suggest some best practice or whatever for establishing those SCOPEs per IdP? I'd like to see it that way (simplified): <Assertion> <Issuer>http://idp.example.com/services/samlImpl</Issuer> ... <Attribute> <AttributeValue>group://idp.example.com/VO1/gr1#ACTUAL_VALUE</..> </...> ... So one SCOPE per IdP + profile has statement which says the it SHOULD be based on Issuer's ID. Does it makes sense?
-) 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
Various SAML attribute profiles rely on this spec:
http://www.ietf.org/rfc/rfc4122.txt
I've been told this is easier to implement, but I can't say for sure. Can you explain in more details what do you mean here, please? I.e. do you want to use the same normalization/comparison rules as are used for UUIDs? I guess no, as it makes no sense for general URI which have non-integer components.
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.
If you're suggesting "isMemberOf" along with the "group:" attribute value syntax can do it all, I agree with you. Yes, exactly. So no problem here.
Best regards Krzysztof