OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [security-services] new version of SAML conformance spec

Title: new version of SAML conformance spec

hi -

i've attached the latest version of the Conformance Spec. It includes the following changes compared to the 07C version:

- References updated for bindings-09 and core-24
- Wording for testing of optional elements changed, such that conforming implementations/applications must be able to handle assertions with optional elements that that the implementation/app does not itself use/support.

- Producer/consumer called out in Table 1.
- Test case included for SOAP profile for impl/app sending query (previously, test cases for SOAP Profile included only the impl/app receiving a query requesting an assertion or artefact)

- Text included regarding test suite (sect 5) and conformance services (Sect 6), rather than TBS

I've also included, as an appendix, a writeup of the issues on SOAP profile being mandatory. I've included the write-up below. Note that it doesn't require all assertions to be implemented in the SOAP profile, only those assertions is claimed in the binding or any profile. So a vendor primarily interested in the web browser/artefact profile could implement just the SOAP bindings relevant to the authentication assertion. Is that what folks had in mind?



Issue: Should any of the bindings or profiles be mandatory for all implementations or applications claiming conformance to the SAML standard?

Because of the importance of interoperability among implementations or applications claiming conformance to the SAML standard, one of the recommendations in this version of the SAML Conformance Specification is to require all implementations or applications to implement the SOAP binding for any assertions it supports (including in other profiles). This ensures that 1) assertions created by the implementation or application can be retrieved using the SOAP binding, either directly or by means of an artefact, and can be inspected for validity; and 2) the ability of the implementation or application to consume assertions generated by another SAML-compliant implementation or application can be verified.

Alternatively, no single binding or profile need be mandatory, as long as an implementation or application claiming conformance is specific regarding which bindings and/or profiles it supports, with what assertions, and for what roles (producer / consumer). (This was the approach taken in the Conformance Specification prior to verion 006. The change resulted from discussion of conformance at the August F2F.)

Issue: Should the SOAP binding be mandatory?
The SOAP binding is suggested as mandatory because it provides the most fully-specified mechanism for requesting and returning all three assertions.

Issue: If the SOAP binding is mandatory, is it allowable to implement a subset of the assertions for that binding?
The current specification suggests that a subset of the SOAP binding (only the authentication assertion, for example) is allowable as satisfying this mandatory binding..



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC