Chad La Joie wrote:
Krzysztof Benedyczak wrote:
- In section 4.1, if you really want that kind of syntax you *may* want to define a special schema type for that encoding, something along the lines of (regexp could be made more precise):
<xsd:simpleType name="groupQualifiedString"> <xsd:restriction type="xsd:string"> <xsd:pattern value=".+@(/.+)*" /> <xsd:restriction> </xsd:simpleType>
Of course - however this pattern depends on the details that weren't fully agreed (example: do we use this syntax only for roles or other attributes too? If so empty values may be permitted before @ what influences the pattern).
I have another remark here. The initial aim of attributes encoded in the '@' fashion was to simplify creation of XACML policies, with requirements for an attribute in a group scope. Having a simple string as a value isn't enough when we use a non-standard XACML DataType (i.e. it will require also a non-standard comparison function). So I'd like to change the requirement for DataType to be a '...#string' here, what in turn requires the schema of the attribute value to be 'xsd:string'.
What do you think?
Yeah, the only way you can really do this type of encoding is over string data types. Depending on what you mean by "requires the schema of the attribute value to be 'xsd:string'" that may or may not be correct. The type certainly has to be an instance of xsd:string, but it could done like the schema fragment I had. The "groupQualifiedString" type is still an "xsd:string".
My concern was about SAML XACML profile. Exactly p. 8.5.4: "The syntax of the <AttributeValue> element's content MUST correspond to the data type expressed in the profile-specific DataType XML attribute appearing in the parent <Attribute> element. For data types corresponding to the types defined in Section 3.3 of [Schema2], the xsi:type XML attribute SHOULD also be used on the <AttributeValue> element(s)." I was not sure if it will be all right with this profile to put "DataType=...#string" and xsi:type="restrictedString". But probably it was my misinterpretation and then the proposed schema is fine.
- Definitely agree that the encoding method described in section 4.2 should be dumped for the reasons given in other responses. So here is the most significant problem for me. I'm not going to reduce functionality of the service because there exist poor clients which can produce error on SAML response from my service. And I need a way to encode arbitrary type of value which is group scoped (e.g. a XML value).
One solution I can see is to limit the VO attributes profile to enumerated attributes only (group, VO, role) which are well established, have common sense and we can enforce the common encoding for them.
Then the only way for a client to get attributes with the scope encoded as in 4.2 would be to ask for all attributes or for all values of some attribute.
Is it fine for you? Or maybe other suggestions?
My concerns here are not with the clients that can't support it, but the ones who crash because of it. I would also not include something in the spec unless you're actually going to use it in the spec. Frankly I don't understand the last sentence. Can you explain it, please?
Best regards, Krzysztof