OpenSAML user discussion

[Brent Putman <>]

Scott Cantor wrote:

Brent Putman wrote on 2009-02-09:
  

On the other hand... if the sender did include xsi:type, and if it's
OpenSAML processing it, it would handle that just fine with the custom
provider type, assuming you have properly registered it of course.
    

Yes, unless you're validating, in which case you also need the schema, which is a problem when you don't know what somebody might send you. xsi:type effectively makes validation impossible in the face of extension. Let's face it, XSD is just broken.
  

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).  Not saying people should run out and do that....


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.

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.