RE: [security-services] Status of and recommendation on SAML versioninfo

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

>> - Regarding real filenames: Schema tools are happiest when they can 
>> use the namespace name as the filename for accessing the schema. This

>> isn't supposed to be required behavior, but it might as well be given

>> the state of the tools.
>
>By "use the namespace name as the filename" do you mean just the part
of 
>the name after the last slash?  Or do you mean that tools expect
namespace
>names to be real URLs via which schema documents can be fetched?

The latter. IMHO, the concern is actually less with instance documents
(ie. actual SAML messages) and more with the two schemas, one of which
imports the other, and both of which import dsig.

The way you bypass the URI is by using xsi:schemaLocation in your
instances (or providing the parser with a mapping of namespace->schema
in some way). Unfortunately, this is more complex when you talk about
the schemas themselves, since you're talking about an official document
that you don't want people to have to change themselves in order to
validate instances.

It basically only works if you use a real URL in the import statement,
or you provide the parser with a custom entity resolver that maps the
system identifier sitting in the import statement to wherever you keep
that schema instance.

>If we used URNs as I proposed earlier, these namespaces might be
called:
>
>  urn:oasis:names:tc:SAML:1.0:saml-assertion.xsd
>  urn:oasis:names:tc:SAML:1.0:saml-protocol.xsd
>
>Would that work given the contraints you mention, or not?

What would happen is that unless you had some kind of architecture in
your parser that somehow knew a special way to resolve the urn:oasis
namespace to a URL, you'd have to use a custom resolver and map those
URNs.

It's worth noting that this doesn't work in Xerces 1.4.4, for example,
because there's a bug in the parser (though it's easy to fix). The point
being not that we have to worry about that library, but that it's not
guaranteed to work everywhere for everyone with the current state of the
art.

Despite that, I still favor a URN, partly because I think using real
URLs is delaying the inevitable reexamination of the whole schema
location issue. Parsers are lazy and should be providing good, standard
ways of locating and caching schemas.

-- Scott