Re: [dss-x] self-describing DSS-X instances

[Andreas Kuehne <kuehne@trustable.de>]

Hi Frank,

let me explain my view on the 'extension' mechanism:

To me the use of an xs:any as a way to extend a given schema is more a
flaw than a feature. The implementor of the spec is left on his own
parsing something unknown and trying to make sense of it. No
schema-generated object models helps along and all types of
interpretation problems show up an runtime! As we write a specification
we MUST specify the structure!
So my approach to this flexibility problem is to create specific schemes
including all elements. This eases the implementation of clients a lot
and puts just a little more effort upon the server.
In your case it is perfectly valid to define a profile that adds a
ds:signature element into the OptionalInputs. And the server offers a
WSDL refereing to a scheme where this ds:signature element is explicitly
mentioned in the OptionalInputs.

Nevertheless we came to the conclusion that directly embedding a
ds:signature into the SOAP / DSSRequest message isn't  a good idea due
to namespace leakage and canonicalization side effects. BAse64 encoding
eases the pain here.

So I strongly reject the need for 'alien' namespace inclusions. The
namespaces must all be known. And this isn't a restriction as sender and
receiver are obliged to know them, anyway!

Yes, the overall amount of parsing may increase. But you surely won't
complain that there is a distinct parsing step to read a X.509
certificate within an XML message. Now there are some additional parsing
required for XML within XML. This is a disadvantage but it enables a
clear distinction between the 'DSS object model' and the different
transport syntaxes. The processing of a request should be the same
regardless of the usage of XML, JSON or whatever. E.G a XAdES object
will be transferred in the same manner, always. And can be accessed at
the same spot in the object model, always. This comes with the
dis-advantage but avoids inter-dependencies between architectural layers.
Therefore the UBL approach of 'any' representations in different
syntaxes helps with our problem: A semantic 'any' may hold any content,
but a XML any is limited to XML, a JSON 'object' limited to JSON, and so
forth.


Greetings,

Andreas

   
> Hi,
>
>
> As one of the goals of DSS 2 is "Support other transport formats than
> SOAP.", message-level security becomes a critical feature I guess.
>
> SOAP security is covered by WS-Security/WS-SecurityPolicy and such. A
> non-SOAP binding requires message-level security, obviously by means
> of XML signatures.
>
>
> I did some more experiments with message-level security. While this
> could be added in DSS 1, see:
>
> https://www.e-contract.be/sites/dssp/dssp-specs/dssp-specs-1.5.1.pdf
>
> section 2.2 Browser POST, due to the AnyType being a base64 in Core 2:
>
>     <dss:SignRequest
> xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema"
> xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema"
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
>     <dss:OptionalInputs>
>         <dsb:Other>
> <dsb:Value>d2hlcmUgZG8gSSBwdXQgbXkgWE1MIHNpZ25hdHVyZT8=</dsb:Value>
>         </dsb:Other>
>     </dss:OptionalInputs>
> </dss:SignRequest>
>
> it becomes impossible to express this.
>
> XML Signatures work at the DOM level, so we really need to be able to
> add "alien-namespace" XML elements.
>
>
> Besides the XML Signature issue, the parsing of additional profiles
> becomes a two-pass operation.
>
> In Core 1, you could add your additional profiles within your WSDL by
> means of a simple import. See example:
>
>     https://www.e-contract.be/sites/dssp/dssp-specs/dssp-ws.wsdl
>
> Feeding this to JAXWS/JAXB made it possible for JAXB to actually parse
> your additional profiles in one go.
>
> With the Core 2, you parse a first time towards base64, and then you
> have to run a second JAXB unmarshalling against this. From a
> usability/performance point-of-view, this becomes really painful.
>
>
>> The structures intended to be supported by a client or a server
>> system MUST be known to be implementable. But the usual tools for
>> schema support leave the task of handling the content of an any type
>> to the developer. Without extensive testing problems with unexpected
>> content may occur at runtime, even while using typed languages.
>>
> An AnyType of unknown namespace (in the context of the parser like
> JAWS/JAXB) simply results in a DOM element, as it should be. I don't
> see the problem here.
>
> Even if one would acknowledge this as a problem, doing a base64 is not
> solving anything at all. The problem remains.
>
>
>
> What am I missing here?
>
>
> I'm already managed to use Jackson for JSON Schema compilation in
> Java. Will play a bit with this AnyType stuff to see if the above
> issues could be resolved in a generic way to keep both XML and JSON
> happy.
>
>
>
> Kind Regards,
> Frank.
>
>
>
> On 01/28/2018 12:16 PM, Frank Cornelis wrote:
>> Hi Andreas,
>>
>>
>> Still have to get acquainted with the JSON Schema specs/tooling, but
>> it seems like OASIS UBL solved a similar problem where both their XML
>> and JSON have extension points, and their XML does it via xsd:any.
>> See:
>> http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Business-Document-NDR-v1.1-csprd01.html#S-EXTENSION-XML-SCHEMA-FRAGMENTS-AND-DECLARATIONS
>>
>> And:
>> http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.1/csprd01/Business-Document-NDR-v1.1-csprd01.html#S-EXTENSION-JSON-SCHEMA-FRAGMENTS-AND-DECLARATIONS
>>
>>
>>
>> BTW: In my “sandbox” project here, as part of my message-level
>> security experiments, I also had to give the new Core 2 XSD a 2.0
>> namespace to be able to compile both Core 1 and Core 2 within the
>> same Java Maven project. Core 2 will eventually receive a new
>> namespace I guess?
>>
>>
>> Kind Regards,
>> Frank.
>>
>>> Op 26 jan. 2018, om 19:47 heeft Andreas Kühne <kuehne@trustable.de
>>> <mailto:kuehne@trustable.de>> het volgende geschreven:
>>>
>>> Hi Frank,
>>> thank you for your feedback!
>>> Yes, it’s an advantage to provide a sample WSDL as implementor’s
>>> support. But due to the support of current frameworks the WSDL
>>> slides towards being a derived artefact.
>>> I was assuming that the binding and the ‘annox’ namespaces, leaking
>>> thru from prior processing steps, are just irrelevant here.
>>> Interesting to see that these declarations do cause problems. Now
>>> I’ll drop them before reaching the final schema stage. Surprisingly
>>> no way to drop namespace declarations that are defined in the
>>> incoming document using XSLT … had to fall back to RegEx.
>>> Regarding the AnyType:
>>> The handy use case of putting some random XML fragment into an
>>> AnyType cannot be supported by the JSON syntax and vice versa. So
>>> the only feasible approach to transport arbitrary data _/and/_
>>> supporting multiple syntaxes is to use some base64 encoded
>>> container. And we already have a fully featured Base64DataType
>>> defined in DSS (with a content describing MIME type attribute,
>>> support for references and attachments). So why not align all usages
>>> to the Base64DataType?
>>> The biggest pain point of the current multi-syntax approach is the
>>> effect on foreign schemes. As outlined in the new core draft,
>>> section 2.6, some well-respected features of XML cannot easily be
>>> mapped to e.g. JSON. So my current approach is to rewrite the
>>> referenced schemes and replace the XML specifics. Yes, bad approach
>>> but I don’t know of any better! Proposals welcome!
>>> Greetings,
>>> Andreas
>>> *Von:*dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org>
>>> [mailto:dss-x@lists.oasis-open.org]*Im Auftrag von*Frank Cornelis
>>> *Gesendet:*Freitag, 26. Januar 2018 15:16
>>> *An:*dss-x@lists.oasis-open.org <mailto:dss-x@lists.oasis-open.org>
>>> *Betreff:*Re: [dss-x] self-describing DSS-X instances
>>>
>>> Hi Andreas,
>>>
>>> Hereby some feedback on the XML schema and such.
>>>
>>> Why change AnyType exactly?
>>>
>>> Kind Regards,
>>> Frank.
>>>
>>> OASIS DSS Core 2 Remarks
>>> ========================
>>>
>>> xml.xsd is missing from the ZIP.
>>>
>>> Always found it funny that there was no proper SOAP binding defined.
>>> See attachment for a first shot at it.
>>>
>>>
>>> === oasis-dss-core-schema-v1.0-os.xsd
>>>
>>> When trying to compile with JAX-WS I get:
>>> org.xml.sax.SAXParseException;
>>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd
>>> <file://home/fcorneli/dssp-2/src/wsdl/oasis-dss-core-schema-v1.0-os.xsd>;
>>> lineNumber: 1; columnNumber: 703; Unsupported binding
>>> namespace"http://annox.dev.java.net"; <http://annox.dev.java.net/>.
>>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc";
>>> <http://java.sun.com/xml/ns/jaxb/xjc>?
>>> Had to remove:
>>>     xmlns:annox="http://annox.dev.java.net";
>>> <http://annox.dev.java.net/>
>>>     jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc"
>>>
>>> === oasis-dss-base-schema-v2.0-os.xsd
>>>
>>> Same error here:
>>> org.xml.sax.SAXParseException;
>>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd
>>> <file://home/fcorneli/dssp-2/src/wsdl/oasis-dss-base-schema-v2.0-os.xsd>;
>>> lineNumber: 1; columnNumber: 555; Unsupported binding
>>> namespace"http://annox.dev.java.net"; <http://annox.dev.java.net/>.
>>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc";
>>> <http://java.sun.com/xml/ns/jaxb/xjc>?
>>> So had to remove:
>>>     xmlns:annox="http://annox.dev.java.net";
>>> <http://annox.dev.java.net/>
>>>     jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc"
>>>
>>> === xmldsig-core-schema.xsd
>>>
>>> This does not seem to be the original XMLDSig XML schema.
>>> Same error here:
>>> org.xml.sax.SAXParseException;
>>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd
>>> <file://home/fcorneli/dssp-2/src/wsdl/xmldsig-core-schema.xsd>;
>>> lineNumber: 23; columnNumber: 579; Unsupported binding
>>> namespace"http://annox.dev.java.net"; <http://annox.dev.java.net/>.
>>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc";
>>> <http://java.sun.com/xml/ns/jaxb/xjc>?
>>> So had to remove:
>>>     xmlns:annox="http://annox.dev.java.net";
>>> <http://annox.dev.java.net/>
>>>     jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc"
>>>
>>> === oasis-sstc-saml-schema-protocol-1.1.xsd
>>>
>>> This does not seem to be the original SAML 1.1 XML schema.
>>> org.xml.sax.SAXParseException;
>>> systemId:file:/home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd
>>> <file://home/fcorneli/dssp-2/src/wsdl/oasis-sstc-saml-schema-protocol-1.1.xsd>;
>>> lineNumber: 1; columnNumber: 705; Unsupported binding
>>> namespace"http://annox.dev.java.net"; <http://annox.dev.java.net/>.
>>> Perhaps you meant"http://java.sun.com/xml/ns/jaxb/xjc";
>>> <http://java.sun.com/xml/ns/jaxb/xjc>?
>>> So had to remove:
>>>     xmlns:annox="http://annox.dev.java.net";
>>> <http://annox.dev.java.net/>
>>>     jxb:version="2.1" jxb:extensionBindingPrefixes="annox xjc"
>>>
>>> On 01/24/2018 03:49 PM, Andreas Kuehne wrote:
>>>> Hi Frank,
>>>> good to see you re-joined DSS-X!
>>>> Attached id the current core document reflecting our latest
>>>> discussions
>>>> regarding the dss:AnyType. In this version the AnyType is replaced
>>>> by a
>>>> Base64DataType.
>>>> As you are interested in Remote Signing I added the schema of the
>>>> ChipGateway profile, too.
>>>> Greetings,
>>>> Andreas
>>>>> Hi Andreas,
>>>>> Were can I find the 2.0 XML schema?
>>>>> I would like to check whether a "Remote Signature" profile with
>>>>> message-level integrity protection could be easily defined against
>>>>> the
>>>>> new 2.0 proposal.
>>>>> Kind Regards,
>>>>> Frank.
>>>>> On 01/24/2018 12:47 PM, Andreas Kuehne wrote:
>>>>>> Hi all,
>>>>>> the current version of the base schema includes a set of types to to
>>>>>> self-decribe the DSS-X server instance (e.g. the
>>>>>> DescriptionType). There
>>>>>> are similiar concepts around, a popular one is HATEOS.
>>>>>> So I would consider to separate this topic from the DSS-X
>>>>>> specification.
>>>>>> Like the TLS details included in core version 1.0 that outdated
>>>>>> quickly
>>>>>> the evolving area of instance meta information may render our
>>>>>> specification effort useless.
>>>>>> What's your view on this?
>>>>>> Greetings,
>>>>>> Andreas
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ;
>>>
>>>
>>>
>>> -- 
>>> Frank Cornelis
>>> e-Contract.be <http://e-Contract.be>  BVBA
>>> https://www.e-contract.be <https://www.e-contract.be/>
>>
>

-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612

Director Andreas Kühne

Company UK Company No: 5218868 Registered in England and Wales