Conditions spelled through xsi:type are refused, and the refusal does not say which

What

The condition readers match on element name. SAML allows the same condition to be spelled through the generic element, <saml:Condition xsi:type="saml:OneTimeUseType"/>, and ConditionsType in the bundled XSD admits it. That spelling lands in unknown_condition and is refused, for AudienceRestriction, ProxyRestriction and OneTimeUse alike. TEST 13 pins this on purpose with xsi:type="saml:AudienceRestrictionType" as its unrecognised case.

Since #53 the XSD leaves Condition as the only element that can reach unknown_condition, so the refusal always reads carries a condition this SP cannot satisfy: Condition, whatever xsi:type it carried.

Why it is not in #53

Refusing is fail-closed and in spec: Core 2.5.1.1 rule 3 makes a condition the SP does not recognise Indeterminate. Accepting the spelling means resolving xsi:type in C for every reader at once; an xsi:type AudienceRestriction accepted as known with its audiences unread would be a bypass. No browser-SSO IdP writes this spelling.

The asymmetry is new

Before #53 both spellings produced the same 401, so behaviour across serializers was at least uniform. #53 promotes the element spelling to accepted while this one stays refused, so an IdP that switches serializers flips from working logins to a hard 401 for every user. #53 also makes Condition the only element that can reach the refusal, which is what reduced the message to a fixed string.

What to do

• Append the xsi:type value to the refusal message, so the one case the log can fire in names the type.
• Decide whether to accept the spelling for the three spec conditions. If yes, resolve xsi:type once and feed every reader from it.

Raised by @jarvis9443 reviewing #53.