RE: Editor comments on Core-12

["Mishra, Prateek" <pmishra@netegrity.com>]

I have made some comments and and linkages to
the disucussion documents and f2f#3 minutes.

 
>
>
>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 am puzzled by this comment. Do you have a specific schema element
in mind? Or is there a specific section of the f2f#3
minutes you are drawing our attention to?


>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. 

There seems to be a misunderstanding here. There is no a priori
notion of object that is being used or referred to in core-12. 
An object is simply a aggregate of {action+, resource). I would
argue that a container is helpful here as the action certainly
refers to a resource and there is some sort of connection or
linkage between the two (no point doing a GET on an EJB method for example).

A specific element was not discussed at the f2f#3 for combining
the two components together. It is also true that the particular
choice of name is not helpful here. At any rate, I see this as
a helpful structuring device but far from essential. 

  
>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  

The proposed interpretation for a missing Authentication code is
that it stands for all possible authentication codes. In other words,
I can either ask for a AuthenticationAssertion with a specific
Auth code or I can ask for Authentication assertions with any
authentication code at all. The case with Auth code missing models 
"any auth code". This is an attempt to model precisely the intent of
Section 4.2 of the f2f#3 minutes (Chapter heading: Authentication 
Assertion discussion, boardwork by Bob Blakley). 

>  - 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.

I do not see an issue here. An examination of the schema
shows that each <SubjectAssertionType> has one or more attributes.
I assume your comment refers to the "or more" part of the schema.

  - 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.  

I am not able to follow the main issue here. A more
direct reference to the core-12 schema elements would be
helpful to me.

The f2f#3 minutes are
reasonably clear on the point that an attribute consisting of a name
(and an optional namespace) may refer to many values. The values themselves
may be arbitrary pieces of XML (the <any> element is used here in
the definition of AttributeValueType --- precisely XML schema wildcarding).
This is the structure captured in the core-12 AttributeType definition.


>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 model adopted in core-12 is to support query by attribute name
ONLY. This is supported by the f2f#3 minutes. A careful reading of Section
2.0 of the Attribute Assertion discussion lists queries of the form: 

     (1) Return a set of AttrAssns containing all attrs for the subhect
     (2) Return *only* ( (ANY | ALL) of the following attributes ...

The discussion of XPATH enters the discussion only tangentially
(following ISSUE:[F2F33-37]) and in ISSUE:[F2F#3-29]. I can see that
perhaps there is need for greater expressiveness in the SAML
query language (e.g., use of XPATH) but the components that have been
included are directly based on the minutes.


_________________

Hope the comments clarify matters,

prateek