[OGSA-AUTHZ] VO SAML Attribute Profile

[Krzysztof Benedyczak]

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