[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Editor comments on Core-12
David,
Here are some responses mostly to help structure the discussion for the
focus group. My apologies for the late reply.
> >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
<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.
[Prateek Mishra] Agreed, I have no further issues in this space.
>
> >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.
[Prateek Mishra]
I would suggest that this issue is at an extremely fine level of
granularity. We
have agreement that we need to model "any" or wildcard query w.r.t.
AuthenticationCodes. Core-12 has one design proposal, you have made another.
IMHO, there is not much to choose between the two approaches.
I would disagree with changing the schema to set "minOccurs=1" as that does
go against
the f2f#3 minutes (implies no support for the "any" or wildcard query case)
The f2f#3 minutes are very clear on the basic requirement; I would propose
we leave this as it is and carry it forward as an design issue.
> > - 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.
[Prateek Mishra]
The f2f#3 minutes suggest that there are two different types of attribute
queries to be supported:
(a) Return all attributes of a subject (minOccurs=0)
(b) Given a list of attribute names, return ALLorNone or ANY of the
attributes (1 or more attributes).
In summary, the minOccurs=0 case corresponds to (a) above.
> - 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.
[Prateek Mishra]
I have absolutely no problem with taking this forward as an issue. But I
would
like to keep it separate from the editorial "issues" discussion around
core-12.
I will therefore not comment upon it.
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.
[Prateek Mishra]
Again, I would like to stay close to the intent of f2f#3. There are many,
many
issues on which we do not have design guidance from f2f#3. I would argue
that to make progress we need to put in some minimal design and try to
move forward.
I think your main point here is not to re-use the <Attribute> element within
an
attribute query. I have no issue with that. We can replace it by
0 or more instances of an AttributeNameType. Notice that the 0 is needed as
some attribute queries will not mention any attribute names at all.
Each AttributeNameType basically consists of a single string name (of an
attribute).
At the same time, you are proposing that <AttributeValue> element have a
minimum cardinality of 1. This ensures that an element of <AttributeType>
always has a value within it.
Chris: can you comment on this piece?
I hope this helps
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC