Krzysztof Benedyczak wrote:
Tom Scavo wrote:
So, your example 8.2 can be expressed as follows:
<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.5.1.1" FriendlyName="isMemberOf"> <saml:AttributeValue xsi:type="xs:string">voName:group</saml:AttributeValue> <saml:AttributeValue xsi:type="xs:string">voName:group:subgroup</saml:AttributeValue> </saml:Attribute>
Here, the group hierarchy is denoted with colons (not slashes), which agrees with Grouper (the follow-on project to MACE-Dir-Groups):
Using this notation, a group name is simply an URN.
I don't think it is an URN - no 'urn:' prefix, no NSS part (which should determine syntactic rules for the tail). Also it clearly offends the RFC in the point: "Global uniqueness: The same URN will never be assigned to two different resources".
Of course I agree that interoperability with the software like Grouper is desirable. But except of it, do we have any other reasons for making it an URN?
Yeah, those group identifiers are not, and never were, URNs, they're just : delimited group identifiers. That said, using URN *might* be a good for one of the reasons you point out, namely, it's likely that you do want these things to be unique. My group "foo:bar" shouldn't collide with your group "foo:bar". Now, the problem with the use of the URN in this case would be that any VO would need to acquire a NSS.
One last comment and I'll stop and let you respond. I would try to avoid defining a scope attribute for the <AttributeValue> element. As you'll see in the MACE-Dir Attribute Profile, Shibboleth defined a Scope attribute early on, an unfortunate incident that the project regrets to this day. Indeed, much of their profile exists solely to work around this legacy Scope attribute. Even though your proposed scope attribute is namespace qualified, it strikes me as a step backward. Can you elaborate on this a little bit more? I think it is the most important and difficult topic in case of the discussed profile. Do you suggest to drop scope information at all or to encode it in different way or in different place? Can you also give more details why it was so "unfortunate" for MACE-Dir? We obviously don't want to repeat the same mistake.
The biggest thing was the havoc it caused with other SAML software. A mistake that we've made numerous time in Shibboleth is assuming that other implementors aren't taking shortcuts. In this case, we assumed that because an AttributeValue could, in theory, contain any type of complex data implementations would either provide a way of handling such data or provide a good way for applications to get at the unaltered data. Neither proved to be true. Most SAML implementations can only really support strings and will totally ignore any type indicator, some (ADFS) will even error out in some cases if you send it more complex data. -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie@switch.ch, http://www.switch.ch