OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Editor comments on Core-12


Title: RE: Editor comments on Core-12

Hi Prateek,

I think I'm supposed to respond to your message as a result of the last Focus Telecon, so I've embedded my response in yours.  

To repeat what I said on the call, my comments simply indicate a few small areas where the core-12 doesn't quite match what I think are in the minutes.  My comments should not in any way take away from what the editors did in creating core-12, as it was good work.  However, I felt uncomfortable in letting these - again what I believe are small divergences - go because I in fact made earlier mistakes in not picking up on them, as ChrisM observed during the call.  I also felt uncomfortable in that the changes may be minor in quantity of code, they are not insubstantial.  For example, the use of minOccurs="1" on attribute values means that an attributeQuery string must be introduced as attributes can't be used as templates. 

I've tried to follow JeffH's directive of proposing and using exact Schema fragments, so this message got a little (lot?) longer than I would have liked.  There are specific schema fragments to illustrate every point.  I think the issues are very clearly elaborated, my points #1,2a, 2b ,4 are editorial and #2a, #3, #4 result in things I'd like to raise as issues.  I've also said what I feel comfortable doing editorially, with a path forward on all of the points.

Cheers,
Dave

> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com]
> Sent: Monday, August 06, 2001 7:33 PM
> To: Orchard, David
> Cc: 'security-services@lists.oasis-open.org'
> Subject: RE: 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 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?
>

I'm particularly looking at the Attribute assertion and the Authorization Assertion structures.  I realized that in some cases, I'm not sure whether the notation used indicates whether a <sequence> or a <choice> is the required schema construct, so I tried to come up with the principle that I could use for interpretation.

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

I think the facts are clear on this.  The current core-12 schema is:
 <complexType name="AuthorizationDecisionAssertionType">
 <complexContent>
         <extension base="saml:SubjectAssertionType">
         <sequence>
          <element ref="saml:Object" />
          <element name="Answer" type="saml:DecisionType" />
          <element name="saml:Evidence" minOccurs="0" maxOccurs="unbounded" />
          </sequence>
          </extension>
  </complexContent>
  </complexType>

  <element name="Object" type="saml:ObjectType" />
 <complexType name="ObjectType">
         <sequence>
          <element name="Resource" type="xsd:uriReference" />
          <element name="Namespace" type="uriReference" minOccurs="0" />
          <element name="Action" type="string" maxOccurs="unbounded" />
          </sequence>
  </complexType>

When the whiteboard at http://www.oasis-open.org/committees/security/minutes/SSTC-F2F-3-whiteboard-2-cropped.jpg indicate that roughly the following should be the schema:

  <complexType name="AuthorizationDecisionAssertionType">
  <complexContent>
          <extension base="saml:SubjectAssertionType">
          <sequence>
          <element name="Object" type="xsd:uriReference" />
          <element name="Action" type="string"/>
          <element name="Answer" type="saml:DecisionType" />
          </sequence>
          </extension>
  </complexContent>
  </complexType>

Now I can live with adding unbounded # of actions, because we clearly talked about something like checking for HTTP GET and POST, so we'd probably want the shortcut of a collection of actions.  I'm not sure about the addition of Evidence, but I don't have the understanding to debate that issue.  It also seems like the AuthorizationDecisionAssertion forgot the namespace as shown in the query, so it makes sense to add one to the structure, despite what the minutes actually say.  These 3 changes would result in a schema like:

  <complexType name="AuthorizationDecisionAssertionType">
  <complexContent>
          <extension base="saml:SubjectAssertionType">
          <sequence>
          <element name="Object" type="xsd:uriReference" />
          <element name="Namespace" type="uriReference" minOccurs="0" />
          <element name="Action" type="string" maxOccurs="unbounded" />
          <element name="Answer" type="saml:DecisionType" />
          <element name="saml:Evidence" minOccurs="0" maxOccurs="unbounded" />
          </sequence>
          </extension>
  </complexContent>
  </complexType>

So where I drew my line of question was at the introduction of a new structure to encapsulate a couple of the elements.  To me, that seemed too far to go from an editorial perspective.  There is an element or 2 that I think would be useful shortcuts and introductions in the spec (as you'll see later in this doc), but I didn't think that I should introduce them via editorial privilege.

I think that you and ChrisM are OK with this, so if PHB doesn't object then we could close this really quickly.

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

That makes sense and is a logical way of implementing an "any" or wildcard query.  But I personally wouldn't implement it that way and the F2F#3 wasn't clear on how to do this.   My proposal that a wildcard would be an explicit special string, rather than having AuthnType optional.  And I wouldn't allow the wildcard to be a special case of the AuthenticationCode as I wouldn't coflate the query about things with things themselves.  So I'd introduce type of the wildcard, then you can always require an AuthnType or the Query (which I like from a conformance perspective), and allow for extensibility in the future.  So my proposed schema would be:

 <complexType name="AuthenticationQueryType">
 <complexContent>
 <extension base="samlp:SubjectQueryType">
 <choice>
  <element ref="saml:AuthenticationCode"/>
  <element ref="saml:AuthenticationCodeAny"/>
  </choice>
  </extension>
  </complexContent>
  </complexType>

<!-- A value of '*' indicated any Authentication Code can be used.  -->
 <element name="AuthenticationCodeAny" type="saml:AuthenticationCodeAnyType" />
 <simpleType name="AuthenticationCodeAnyType">
  <restriction base="string" />
  <enumeration value="*" />
  </simpleType>

However, this is certainly not an editorial interpretation of F2F#3, so I do not suggest putting this in the doc, even if I'm sure that it's the right design ;-).  I suggest for now that the AuthenticationCode be minOccurs="1", and we can then debate in an issue how to deal with the any. 

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

Right now, AttributeQueryType has
<element ref="saml:Attribute" minOccurs="0" maxOccurs="unbounded" />

It's the minOccurs="0" that I think is incorrect.  That's the issue.  I'm ok with editorially adding the maxOccurs.

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

Ah, but the <any> element is only on the value of the attribute, not on the name or structure.  This precludes me from differentiating between <person><name>Dave</name></person> and <JobTitle><name>Architect</name></JobTitle>.  The name of the attribute may not be sufficient to model the structure, hence why we want XML schema and wildcarding for the entire name/value structure. 

Please note that I believe the following is a substantive issue with core-12, rather than an editorial issue.  There was nothing wrong with the transcription from the minutes into core-12, I just don't think we thought this aspect through far enough so I think this should be an issue.

Now one of the principles that I'm trying to follow is to very and extremely clearly differentiate between things (like attributes, authenticationcodes, etc.) and queries about things.  So separating them is useful to me.

To carry Jeff's request for concrete schema fragments further, I think the schema should be:

        <!-- alternatively, the attribute and extended attribute structures from core-09 could be used -->
        <complexType name="AttributeAssertionType">
                <complexContent>
                        <extension base="saml:SubjectAssertionType">
                                <choice>
                                        <element ref="saml:Attribute" maxOccurs="unbounded"/>
                                        <any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

                                </choice>
                        </extension>
                </complexContent>
        </complexType>

        <complexType name="AttributeQueryType">
                <complexContent>
                        <extension base="samlp:SubjectQueryType">
                                <sequence>
                                        <element ref="saml:AttributeQueryString"  maxOccurs="unbounded"/>
                                        <element name="CompletenessSpecifier" type="samlp:CompletenessSpecifierType" default="All"/>

                                </sequence>
                        </extension>
                </complexContent>
        </complexType>

        <element name="AttributeQueryString" type="saml:AttributeQueryStringType"/>
        <complexType name="AttributeQueryStringType">
                <choice>
                        <element name="AttributeName" type="string"/>  <!-- this matches against saml:attributes-->
                        <element name="ExtensionQuery" type="string"/>  <!-- this matches against the any section -->
                </choice>
      </complexType>

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

The is the re-use of the attribute assertion to hold the query for attribute assertions, ala templating.  We very specifically (the + on attribute value is one or more ) agreed to

        <complexType name="AttributeType">
                <sequence>
                        <element name="AttributeName" type="string"/>
                        <element name="AttributeNamespace" type="uriReference" minOccurs="0"/>
                        <element name="AttributeValue" type="saml:AttributeValueType" maxOccurs="unbounded"/>
                </sequence>
        </complexType>

The difference between minOccurs="0" and minOccurs="1" is the nub of the issue.  Given that + means 1 or more, we have no choice in this.  And I as TC member will/would argue very strenuously against overturning F2F #3 on this.

The result is that an attribute Query specifying an Attribute (which now requires a value) makes NO sense.  So we need to introduce a query intermediary type (which we've done before for other query types), like I suggested earlier in this message and now copy:

        <complexType name="AttributeQueryType">
                <complexContent>
                        <extension base="samlp:SubjectQueryType">
                                <sequence>
                                        <element ref="saml:AttributeQueryString"  maxOccurs="unbounded"/>
                                        <element name="CompletenessSpecifier" type="samlp:CompletenessSpecifierType" default="All"/>

                                </sequence>
                        </extension>
                </complexContent>
        </complexType>

The minutes of F2F #3 do not give us a clear and consistent design on this, so editorially I suggest that we make the attributeValue into minOccurs="1", then introduce a simple structure for the query, give the alternatives for the structure, and raise it as an issue.

I hope this helps



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC