RE: [security-services] Proposed addition to Section 3.3 of Conformance

["Philpott, Robert" <rphilpott@rsasecurity.com>]

I think this clarification would help as well.   So, here's yet another try:

--------------------------
Conforming SAML implementations must permit the use of all identifier constants described in Sections 8.2 and 8.3 when producing and consuming SAML messages. SAML message producers must be able to create messages and SAML message consumers must be able to process messages with any of the constants present in these sections. In this context, "process" means that the implementation must successfully parse and handle the identifier without returning any type of fault. How the implementation deals with the identifier once it is processed at this level is out of scope.

A SAML implementation can provide the facilities described above through direct implementation support for the identifiers or through the use of supported programming interfaces. Interfaces provided for this purpose must allow the SAML implementation to be programmatically extended to handle all identifiers in section 8.2 and 8.3 that are not natively handled by the implementation.

Note that sections 8.3.7 (persistent name identifiers) and 8.3.8 (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. The remaining identifiers in sections 8.2 and 8.3 specify no normative processing rules.  Since no normative processing rules exist for the other identifiers, generation and consumption of these identifiers is meaningful only when the generating and consuming parties have externally-defined agreement on the semantic interpretation of the identifiers.

<need additional text explaining that the consent identifiers (section 8.4) are not MTI>
---------------------------
Rob Philpott
Senior Consulting Engineer 
RSA Security Inc. 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 
mailto:rphilpott@rsasecurity.com
________________________________________
From: Anthony Nadalin [mailto:drsecure@us.ibm.com] 
Sent: Wednesday, January 05, 2005 12:13 PM
To: Scott Cantor
Cc: Philpott, Robert; security-services@lists.oasis-open.org
Subject: RE: [security-services] Proposed addition to Section 3.3 of Conformance

OK, then "process" is somewhat nebulous, what should be stated is that a no fault is returned. Support and process in my mind are 2 different things, so I can process the identifier but may just ignore and thus not support and the implementation should still be conformant.

Anthony Nadalin
"Scott Cantor" <cantor.2@osu.edu>

"Scott Cantor" <cantor.2@osu.edu> 
01/05/2005 10:52 AM

To

Anthony Nadalin/Austin/IBM@IBMUS

cc

"'Philpott, Robert'" <rphilpott@rsasecurity.com>, <security-services@lists.oasis-open.org>

Subject

RE: [security-services] Proposed addition to Section 3.3 of Conformance





> Since a implementation may not support all, then 
> "successfully process" could mean ignore or send fault/error. 
> I just don't know what this will achieve. 

If an implementation doesn't support them all, it's non-conformant, that's
the entire issue. I don't know why this is such a contentious problem.
"Support" means "can be configured or extended to successfully
consume/process". That's it.

It doesn't mean return a fault. It pretty much does mean ignore in this
case, because SAML consumers don't have to do anything to process an
identifier. But they can't be hardwired to return a fault just from seeing
one. That's useless. Can I produce a SOAP stack that faults on every call
and be "conformant" with SOAP (assuming it had conformance)? Of course not.

A conformance test for this is easy...you generate each possible format and
make sure that the product doesn't fault.

-- Scott