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.

Since we don't have "faults" in SAML, this wouldn't be a useful statement.

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

I disagree with that characterization. As a feature for conformance, support
should mean successfully handling something, fulfilling the obligations of a
particular role.

But a SAML consumer has no real obligation to do anything with an identifier
other than not fail because a customer wants to use one in a query or accept
one in a protocol. So it can "ignore" it in some cases (such as SSO) and
still be conformant, but in the act of ignoring it, it successfully
processed it. Focusing on the "ignorability" isn't useful because it's
specific to cases in which there are no real requirements on the
implementation. That's not always (or even often) true.

The only reason I mention it at all is to justify my position that
"supporting" all formats in the spec isn't onerous for somebody supplying an
SP implementation.

But I would agree that "process" is not the same as "support". I can
"process" something with a failure, but I don't see how that works with
"support" unless supporting a feature becomes a useless qualifier.

-- Scott

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