Transient IDs and SAML Conformance

[Eric Tiffany <eric.tiffany@ieee-isto.org>]

I'm seeking guidance on the interpretation and intent of the SAML 2.0
Conformance document discussion of Name ID formats in section 3.3.

To summarize, my interpretation in formulating the Liberty Interoperable
testing procedures has been that "trivial processing" of messages --- that
is, correctly processing messages but only issuing error responses rather
than doing something useful --- is not acceptable.  In particular, our
testing requires that implementations accept Transient Name IDs, and use
them to allow access to protected resources.

There is at least one party who disagrees, noting that the SAML 2.0
Conformace docs state that the processing rules don't cover what an
implementation does with the ID once the SAML processing is done.  In this
interpretation, an implementation which accepts a Transient Name ID, but
simply rejects the message, is conformant.

To me, the notion that this behavior could be conformant (in any practical
sense) seems anathema. If I were a customer and bought a "conformant"
product which  "supported" Transient IDs, and then found out that  Transient
IDs are  "supported" by summarily rejecting them, I might be upset.

So I think there may be a need to clarify the language in the SAML
Conformance  document, depending on the feedback here.

Here are the relevant sections from the SAML 2.0 Conformance doc:

Lines 199-201 in particular state that

    Sections 8.3.7 [of SAMLCore] (persistent name identifiers) and
    8.3.8 [of SAMLCore] (transient name identifiers) define normative
    processing rules for the producer of such identifiers. All
    normative processing rules in Sections 8.3.7 and 8.3.8 MUST be
    supported by conforming implementations.

and lines 205-208 state:

    Note: In this context, "process" means that the implementation
    must successfully parse and handle the identifier without failing
    or returning an error. How the implementation deals with the
    identifier once it is processed at this level is out of scope for
    this specification.

I guess I would say that the definition of "process" here needs to be a bit
tighter --- and for a conformance spec, perhaps needs to go a bit beyond the
spec in terms of setting expectations.  For example, with a Persistent ID,
an implementation might claim to be conformant even though it rejects all
Persistent IDs --- but that would eliminate the possibility of Single-Logout
or NameID Management.

Anyway, your thoughts are appreciated.

ET
-- 
____________________________________________________
Eric  Tiffany             |  eric@projectliberty.org
Interop Tech  Lead        |  +1 413-458-3743
Liberty Alliance          |  +1 413-627-1778 mobile