RE: [security-services] Suggestion for conformance of NameIdentifier

From: Thomas Wisniewski [mailto:Thomas.Wisniewski@entrust.com]

Cameron, 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 identifier formats.

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 discussion.

security-services message