[security-services] Comments on core-26

[Irving Reid <Irving.Reid@baltimore.com>]

I'll separate this message into sections. The first section has
"substantive" changes; the second has corrections that I'm pretty sure
represent the will of the committee; the third section has purely editorial
changes.


Substantive changes:
-----------------------------------------

Lines 499-450: The text specifies that "If the value... is omitted or is
equal to the start of the epoch, it is considered unspecified.", but we
never define what the "epoch" is or how it should be represented as an XML
dateTime. I propose that we change the text to remove mention of the epoch.


Lines 631, 637-641: The text still makes it sound like a statement can have
multiple subjects. I suggest we change to:

631: The <Subject> element specifies the system entity [or should this be
principal?] that is the subject of the statement. It contains...

637-641: If the <Subject> element contains both a <NameIdentifier> and a
<SubjectConfirmation>, the issuer is asserting that if the relying party
performs the specified <SubjectConfirmation>, it can be confident that the
entity presenting the assertion to the relying party is the entity that the
issuer associates with the <NameIdentifier>.


823-842: Section 2.4.4.1, about <Actions> and <Action>. All our other
namespace/name combinations are structured so that a single name and
namespace are bundled together. This one is different - the namespace is in
the outer enclosing element, and then the list of contained names are all
considered to be within that namespace.

If I was in a Modest Proposal mood I'd suggest getting rid of the namespace
and switching to anyURI for the name. I'm not in such a mood, so instead
I'll suggest changing the structure to be the same as NameIdentifier:

<element name="Action" type="saml:ActionType"/>
<complexType name="ActionType">
  <simpleContent>
    <extension base="string">
      <attribute name="Namespace" type="anyURI"/>    <!-- Do we want this to
be required? -->
    </extension>
  </simpleContent>
</complexType>

and the corresponding change at line 813: replace <element
ref="saml:Actions"/> with <element ref="saml:Action" maxOccurs="unbounded"/>


997: Section 3.2.1.1, Element <RespondWith> - this element has the same
extensibility issues I discussed in my separate email about AuthorityBinding
(http://lists.oasis-open.org/archives/security-services/200202/msg00127.html
). Since both RespondWith and AuthorityKind are talking about the same thing
(what kind of Statements does an entity have or want), they should use
exactly the same representation. Even if we don't make this change, the text
in lines 1010-1020 must be fixed to remove the obsolete SingleStatement and
MultipleStatement, and to make the acceptable values into URIs to match the
declared type in line 1024.


1645-1653: Section 7.1.9 Object Authenticator subject confirmation method.
The description implies that the subject of an assertion is a piece of
binary data; the TC decided that subjects must be Principals (or system
entities or whatever we're calling them), not data. I suggest that we remove
this ConfirmationMethod.




Corrections:
-----------------------------------------

Lines 507-510: All time instants are interpreted as Universal Coordinated
Time as described in Section 1.2.1  (Remove mention of explicitly indicating
time zone)


Lines 886-887: the AttributeName must be use="required"; the
AttributeNamespace probably also should be use="required".



Editorial Changes:
-----------------------------------------

Line 33: Irving Reid, Baltimore Technologies  (add Technologies)

Line 731: s/AuthenticationBinding/AuthorityBinding/

Lines 1042, 1044: s/an assertion/assertions/, since the request contains
"one or more" AssertionIDReferences or AssertionArtifacts

Line 1194: <Signature>[zero or one] to match corresponding change in schema
(line 1199)


 - irving - 


-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended 
for the addressee(s) only.  If you have received this message in error or 
there are any problems please notify the originator immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for direct, 
special, indirect or consequential damages arising from alteration of the 
contents of this message by a third party or as a result of any virus being 
passed on.

 
This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.