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".
- 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.
- In those attributes defined in section 5, I didn't see anything that indicated whether these attributes were meant to be single or multi-valued. VO attribute is single and group and role are multi, I would guess. No restriction. Subject can be a member of multiple VOs of which all are registered and handled by one service (==SAML assertion issuer). For me a VO attribute is nothing else then the top level group.
Okay, that's fine. Probably just want to say that in the spec.
- In section 5.2 you declare a group attribute. In section 5.3 you declare roles, within the scope of a group. However, you don't have any wording about how you would expect a client to react if a group, given in the scope qualifier of the role, is not included in the list of groups the user is a member of? i.e. role says I'm "admin" in group "foo", but the group attribute doesn't say I'm in group "foo". Very good point! I would add a note to the profile that service can issue attribute statement for S with a role attribute R@/VO/group only if S is a member of /VO/group.
Yes, that seems reasonable. -- 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