Multi-profile support

[Frank Cornelis <info@e-contract.be>]

Hi,

Started playing with a message-level security profile (see previous emails). Initial XML schema looks as follows:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

           targetNamespace="urn:dss:security"

           xmlns:sec="urn:dss:security"

           xmlns:wsa="http://www.w3.org/2005/08/addressing"

           xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"

           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

           elementFormDefault="qualified" attributeFormDefault="unqualified">

    

    <xs:import namespace="http://www.w3.org/2005/08/addressing"

               schemaLocation="ws-addr.xsd" />

    

    <xs:import namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"

               schemaLocation="oasis-200401-wss-wssecurity-utility-1.0.xsd"/>

    

    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema.xsd"/>

    

    <xs:group name="SecurityGroup">

        <xs:choice>

            <xs:element name="Security" type="sec:SecurityType">

                <xs:annotation>

                    <xs:documentation>

                        Defines message-level security.

                    </xs:documentation>

                </xs:annotation>

            </xs:element>

        </xs:choice>

    </xs:group>

    

    <xs:complexType name="SecurityType">

        <xs:sequence>

            <xs:element ref="wsa:MessageID">

                <xs:annotation>

                    <xs:documentation>

                        A unique identifier for this message.

                    </xs:documentation>

                </xs:annotation>

            </xs:element>

            <xs:element ref="wsu:Timestamp">

                <xs:annotation>

                    <xs:documentation>

                        Message should only be used within this time frame.

                    </xs:documentation>

                </xs:annotation>

            </xs:element>

            <xs:element ref="wsa:ReplyTo">

                <xs:annotation>

                    <xs:documentation>

                        The URL to which the DSS should send a response message.

                    </xs:documentation>

                </xs:annotation>

            </xs:element>

            <xs:element ref="ds:Signature">

                <xs:annotation>

                    <xs:documentation>

                        The message signature.

                    </xs:documentation>

                </xs:annotation>

            </xs:element>

        </xs:sequence>

    </xs:complexType>

</xs:schema>

A profile author can always also publish the corresponding redefine XML schema. Example:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

           xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema"

           targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"

           xmlns:sec="urn:dss:security"

           elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:include schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/>

    

    <xs:import namespace="urn:dss:security" schemaLocation="dss-security.xsd"/>

    

    <xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd">

        <xs:complexType name="OptionalInputsSignType">

            <xs:complexContent>

                <xs:extension base="dss:OptionalInputsSignType">

                    <xs:group ref="sec:SecurityGroup"/>

                </xs:extension>

            </xs:complexContent>

        </xs:complexType>

    </xs:redefine>

   

</xs:schema>

A DSS vendor however will always have to define its own top-level redefine XML schema, in function of the selected set of profiles that they want to implement. So it is up to the DSS vendor to “glue” together all profile redefine XML schemas into a single instance. Depending on the complexity of the selected profiles, this could become a non-trivial task. An example where I glue together two profiles:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

           xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema"

           targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"

           xmlns:sec="urn:dss:security"

           xmlns:my="urn:dss:myextension"

           elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:include schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/>

    

    <xs:import namespace="urn:dss:security" schemaLocation="dss-security.xsd"/>

    

    <xs:import namespace="urn:dss:myextension" schemaLocation="dss-example-extension.xsd"/>

    

    <xs:redefine schemaLocation="oasis-dss-core-schema-v1.0-os.xsd">

        <xs:complexType name="OptionalInputsSignType">

            <xs:complexContent>

                <xs:extension base="dss:OptionalInputsSignType">

                    <xs:sequence>

                        <xs:group ref="my:mygroup"/>

                        <xs:group ref="sec:SecurityGroup"/>

                    </xs:sequence>

                </xs:extension>

            </xs:complexContent>

        </xs:complexType>

    </xs:redefine>

   

</xs:schema>

You kind of lose the “orthogonality” of profiles in this way.

Another important aspect is the support of the xs:redefine construct within the different SOAP stacks out there. For our DSS we provide 4 SDKs:

Java: https://github.com/e-Contract/dssp

WCF .NET: https://github.com/e-Contract/dssp-client

PHP: https://github.com/e-Contract/dssp-php

NodeJS: https://github.com/e-Contract/dssp-nodejs

Still have to see to what extend PHP and NodeJS have support for xs:redefine, as they both provide a non-mature SOAP implementation (compared to Java and .NET that is). If they don’t offer xs:redefine support, this becomes a real show stopper.

Another side-effect of the redefine extension mechanism that I just noticed:

If I look back on how we positioned our DSS, the set of profiles we implement evolved over time quite drastically.

In our SDK clients, we simply ignore new response message elements. This allows the DSS to “grow" without the need for constant syncing with all integrating RP clients.

The redefine extension mechanism assumes that each RP always has full knowledge of all received XML elements. If a DSS adds a new XML element within the response messages, and the RP client did not import the corresponding XML schema for this, the RP client will error on this because of the “alien” elements. This could limit a DSS vendor in adding new response message elements (without a corresponding request message element by the RP). A “mustUnderstand=false/true” extension mechanism would not have this side-effect.

Kind Regards,

Frank.