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] | [List Home]

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
Inactive hide details for "Scott Cantor" <cantor.2@osu.edu>"Scott Cantor" <cantor.2@osu.edu>

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

          01/05/2005 10:52 AM


Anthony Nadalin/Austin/IBM@IBMUS


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


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

GIF image

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