OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

>> - 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
>the name after the last slash?  Or do you mean that tools expect
>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
>  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

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC