RE: [security-services] Addition of more wildcarding

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

> Actually, what's the problem with making ID a SHOULD instead of MUST?

Well, mainly the fact that we do things like request/response correlation,
and so forth.

But maybe we shouldn't dismiss out of hand some kind of built-in migration
to xml:id by making ID optional.

Is this worth trying?

The tricky bit is that even though xml:id would be schema-legal for all 2.0
implementations, it wouldn't be "parser-legal". Anybody using an actual XML
parser (as opposed to hand-parsing) would get errors until the parser
supported xml:id. At least I think so, xml: is supposed to be a reserved
namespace prefix that you can't use unless it knows about the attribute.

It seems like it would be messy to have people generating "compliant" SAML
2.0 that couldn't be accepted by all 2.0 products, no?

I suppose it could be done with a 2.1 spec that was backward-compatible, but
not forward-compatible. 2.1 products would handle 2.0 without much incident,
but 2.0 products would choke on 2.1 messages, since they would carry the
xml:id instead.

-- Scott