just to touch on your comment about interop. I would think that persistent
would be a mandatory identifier format. Therefore if persistent (and transient
as you pointed out) are used, two implementations can interop. The other can be
used in an interop iff their interpreted Name Identifier content is same (or
some other way defined).
[RSP] As I mentioned on the call, I think it is important to
remember that the SAML conformance document is talking ONLY about what it means
for a SAML implementation to be conformant TO THE SPECIFICATION. This is
NOT sufficient for ensuring that 2 conforming implementations will ever be able
to interoperate. The former is, IMHO, a prerequisite for the latter to
happen, but it is not sufficient.
That said, the conformance spec already does state that
persistent identifiers are MTI; so are transient identifiers; so are Kerberos
identifiers, so are X509SubjectName identifiers…. To repeat it, a
conforming product must be able to generate and/or consume all of these name
Since the persistent and transient identifiers are the only
formats that include normative text regarding how to create them and process
them, these normative processing rules are also MTI when those identifier
formats are used.
This does NOT however, imply that a vendor that ships a conformant
product MUST ship out-of-the-box support for either persistent or transient
identifiers. They may only support, for example, the emailAddress format.
But as long as their product provides facilities (e.g. APIs) that permit
extending the product such that it can handle these other formats and the
normative processing rules that go with them, they’ve met the requirement
for conformance. But without putting in those extensions, there is no
assurance that the product will interoperate with any other product.
At least, that is how ** I ** interpreted today’s