OpenSAML user discussion

["Scott Cantor" <>]

Brent Putman wrote on 2009-02-09:
> Yeah, sure, agreed on the technical issues.  But if you cared enough on the
> receiver-side to have custom providers registered for that schema type
> (which implies that you were expecting to receive it), and you were also
> validating, then presumably you'd also have the schema and register it in
> your schema validation mechanism  (which I believe the Java OpenSAML code
> handles pretty easily). 

Sure, you might, but other people that might be on the receiving end might 
not. The point is that the library will handle unknown extension types, but 
the validator won't.

> I suppose one could argue that in any schema-typed world, XSD or otherwise,
> that: if you want to care about schema validation, then you have to know a-
> priori what you are willing to accept, based on out-of-band agreement.  And
> if someone sends you something that you don't understand, then it *should*
> fail, by design.

That would be too brittle a system, unfortunately.

> I understand the practical interop issues, but I don't see it as
> materially different than receiving a SAML Assertion Condition you don't
> understand, or a cert with an X.509 Extension marked as Critical that
> you don't understand, or a SOAP header that has mustUnderstand=true that
> you don't, all of which obligate the receiver/processor to fail to
> accept.  To me, an xsi:type is like an implicit "must understand",
> except it's about data model and validity.

That's exactly what it is, but in most cases, critical semantics are harmful 
to interop, and are certainly not universally desired. It would be fine if 
XSD had a way to signal that, but it treats all types as critical. There's no 
lax option for types, only wildcards.

-- Scott