RE: Editor comments on Core-12

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Title: Editor comments on Core-12

 

0. Any time I see a struct with top level elements, I believe that at least 1 of the top level elements must be required.  Otherwise we used the optional notion.  In most cases, all the top level elements must be required as well. 

I do not understand this comment.  

1. Object as described in Core-12 has resources and "actions" in it, and it should be separate.  For example, AuthorizationDecisionAssertionRequest from the white-board has an Object and an Action, whereas the Schema has Object which contains Resource and Action.  If some of the editors whish to change the notion of objects to have actions, then it should be as a proposal.  As a TC member, I would lobby against having object mean resource + action.

You mean Subject, Object Verb? That is what we had in Core-07     

The issue (if you want toi make one) is strictly aesthetic, whether you consider the verb to be 'is authorized' or the action. Personally I think the verb 'is authorized' is implicit in the assertion type.

Raising the action one level in the structure would not have any semantic impact on SAML. It would require the current text to be rewritten. The only consequence that I can think of is that it might affect XACML. I can imagine that you might want more of a separation there so you can talk about objects and actions separately. But even that is a stretch.

 
2. A few of the structures do not have quite the right cardinalities in them.  The particular structures are:
  - Authentication queries should have 1 authentication code in them, not 0..1 
  - Attribute queries should have at least 1 attribute name in them.  According to the actual minutes, the possibility for unbounded # of attributes is excluded.  But I think this was probably a whiteboard scriber error rather than an explicit TC decision. 

On Authentication queries you are wrong. The client quite likely does not have any knowledge of the authentication mechanism that was used. Requiring the client to specify the authentication type in a query would effectively stop most systems from working.

Again on the attribute queries, I should not be forced to require the client to specify the attribute.  

  - See #4 for Attribute Queries.
 
3. The treatment of wildcard attributes is a bit confusing. I had understood that we were supporting structured attributes through the XML Schema wildcard mechanism, but that is not captured in the minutes nor in the schemas.  I think this means I would like to raise an issue that we do not currently support attributes defined using XML Schema structures.  We do support attributes defined using Name/Value pairs.  Both the previous document submissions had support for this construct.  We do have a wildcard for attribute value, but that only means we can have structured values and not general structures.   

If you are going to write an extension schema you might as well define your own attribute assertion. 

4. The treatment of attribute values is a bit confusing.  The minutes indicate that attributes MUST have a name and MUST have 1 or more values.  But the attribute Query refers to attributes and mentions XPath.  I believe this is indicating that there is an Attribute query String rather than a structure.  So I do not believe the attribute query can refer to an attribute, it must refer to a different "type", such as an attribute Name type.  When/if we do support wildcard attributes, then this will make even more sense as we'll need a place for the query string like XPath.  
 

The string XPATH does not appear in my copy of the document.

 

    Phill

Phillip Hallam-Baker (E-mail).vcf