Comments on sstc-saml-core-2.0-draft-17.pdf ( long)

[John Kemp <john.kemp@nokia.com>]

Below are some comments on the current last call draft available at [1],
including some proposed text changes.

Cheers,

- JohnK

Line number references are to the above-named draft document accessed at
[1]:

212-220

Given that we have several more protocols than previously, and that not
all of these protocols are directly involved in transmitting or
requesting assertions, I think the introduction should be broadened a
little - something along the lines of:

"The Security Assertion Markup Language (SAML) defines the syntax and
processing semantics of assertions made about a subject by a system
entity. In the course of making, or relying upon such assertions, SAML
system entities may use other protocols to communicate aspects either
regarding an assertion itself, or the subject of an assertion. This
specification defines both the structure of a SAML assertion, and the
associated set of protocols, in addition to the processing rules
involved in managing a SAML system."

I suggest replacing the sentence starting on 212, ending on 213, with
the above.

216-217

We now have both bindings and profiles. I think we need to briefly
discuss the relationship between the two (enough for an implementer to
be able to know roughly how to proceed), and then lead the reader to
[SAML-TechOvw] for more info.

309-320

Although "subject-less" assertions are not currently defined by SSTC, we
offer the capability for those extending  the SAML assertion schema to
make use of the optionality of the <Subject> element now defined in the
assertion itself. I think we should note a) roughly on line 318, that
"SAML assertions are usually made about a <emphasis>Subject</emphasis>
(see [SAML-Gloss]). However, the <Subject> element of the assertion is
optional, and other specifications may utilize the structure of the SAML
assertion to make similar statements without specifying a subject." and
b) we should define "subject" in the glossary, if we don't already, and
reference that from here.

351-352

I think we need to say a bit more about Name Identifiers, by way of
explanation. I think there's quite a lot of good stuff in the section at
the end of the document where the various formats are defined, but it
references some things that should probably also be up front here. I
recommend something like the following be inserted at line 352:

"Given that the SAML protocol enables third-party authentication of a
subject, in addition to a number of other circumstances where two system
entities (where one entity may even be acting on behalf of an
<emphasis>affiliation</emphasis> (see [SAML-Gloss], [SAML-TechOvw]) may
communicate regarding a third party, it is useful to establish a means
by which parties may be associated with identifiers that are meaningful
to each of the parties. In some cases, it will be necessary to limit the
scope within which an identifier is used to a small set of system
entities (to preserve the privacy of a so-named subject, for example).
Similar identifiers may also be used to refer to the issuer of a SAML
protocol message or assertion. It is possible that two or more system
entities may define the same name identifier to refer to different
identities. Thus, each entity may have a different understanding of that
same name. SAML provides a <emphasis> name qualifier</emphasis> to
disambiguate the name identifier by effectively placing it in a
<emphasis>namespace</emphasis> (perhaps we need to define 'namespace'
separately from XML namespace???) related to that qualifier.

Name identifiers may be encrypted to further improve their
privacy-preserving characteristics, particularly in cases where the
identifier may be transmitted via some intermediary."

Note that I mention "affiliation" in there - I don't see any mention of
that concept in [SAML-Core] until we get to the section on NI formats,
so I just want to make sure that the glossary and tech overview have
something about affiliations in there. I don't really see such a great
place to talk specifically about it in [SAML-Core] but that's probably
OK if we have reference to the relevant places.

501-502

Regarding the subject-less assertions - SAML defines assertions that
*may* have no subject, but does not define any semantics around those -
should we not just say that more explicitly to prevent confusion? It
seems to me that SAML doesn't (currently) have a profile where subject
is omitted - other specifications either as a future piece of SAML, or
outside of SSTC may exist that create such a profile, but that is
outside the scope of this specification - so I would suggest stronger
language here to note that there are currently no semantics in SAML for
this, unless you really wish to leave it ambiguous (which I'm not
against BTW if that's what you intend?)

658 - If one can only ever supply one OneTimeUse element, why is this
restricted in prose instead of schema? Should we not explain that
reasoning? BTW - line 772 duplicates the MUST

663 - same comment as above, and MUST is also duplicated at line 803

774 and 805 - I am not sure what these sentences actually mean - "for
the purposes of determining the validity of the <Conditions> element,
the XXXX is considered to always be valid" - are you really saying that
the system entity evaluating the <Conditions> need not take these
conditions into account when determining overall validity of the
<Conditions> element?

863-870

I notice that the encrypted assertion type looks a lot like the
encrypted NameID type. I was wondering whether these could be derived
similarly - ie. define a BaseEncryptableType, and put the EncryptedData,
EncryptedKey into it. Then one could derive both the BaseID (or just the
EncryptedNameID I guess) and EncryptedAssertion from the same base type.
Not only that, it would possibly allow others to encrypt other things. I
guess I'm not totally sure how to model multiple inheritance or
interfaces in XML...

874 - I think that the abstract statement type is used not only by
"other assertion-based applications" but also by SAML statements. Not
wanting to confuse the reader, I think we should say so, and note that
"other specifications may create assertion-based frameworks by extending
the StatementAbstractType" or something similar.

898 - SubjectLocality - presumably this should refer to the subject
specified at the assertion-level? Should we say that?

906 - Speaking of which, this sentence is indented, which made it hard
for me to see that we do in fact make the Subject required in the
assertion contains an AuthnStatement. We might want to remove the
indentation at least, but I think this sentence should actually move up
to the introductory paragraph - roughly line 886 seems like a good place.

965 - 980

The authentication context content model allows one to basically put
nothing inside an instance of the element - is that desirable? Should we
make a top-level <choice> group that allows multiples of the
decl/class/refs with a minOccurs = 1 (ie. no point in including an
AuthnContext if you don't make at least one (and as many as you want)
statement(s)).

1097-1102 - same comments about creating a BaseEncryptableType and
having the EncryptedAttribute element derive from that....

1232-1239 - again, no discussion of what profiles do, or of [SAMLProf]
generally

1318 - 1320 (also applies to 1382)  - lines are indented where they
probably shouldn't be. Also, this sentence makes me ask the question -
"What should I do if there's no signature present?" Can I also not rely
on the request?



[1]
http://www.oasis-open.org/committees/download.php/7737/sstc-saml-core-2.0-draft-17.pdf