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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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

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

Hi,


Using xs:include works:

<?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"
           xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema"
targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"
           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: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:group ref="my:mygroup"/>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:redefine>

</xs:schema>



Kind Regards,
Frank.



On 01/29/2018 06:02 PM, Frank Cornelis wrote:
To fast... XML Schema validation does not accept the redefined XML schema: 

        Schema schema = schemaFactory.newSchema(schemaSource);
        Validator validator = schema.newValidator();
        validator.validate(new DOMSource(document));

gives me:
        Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.132 sec <<< FAILURE! testXMLGeneration(org.oasis.dssx.dss.XMLTest)  Time elapsed: 0.131 sec  <<< ERROR! org.xml.sax.SAXParseException; lineNumber: 9; columnNumber: 119; src-import.1.1: The namespace attribute 'urn:oasis:names:tc:dss:1.0:core:schema' of an <import> element information item must not be the same as the targetNamespace of the schema it exists in.     at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) 


Anyone a working example for this???


Kind Regards,
Frank.

On 01/29/2018 05:47 PM, Frank Cornelis wrote:


Resending to the group...


On 01/29/2018 05:46 PM, Frank Cornelis wrote:

Hi Andreas,
It took me a while to construct a working example of such extension that could be referenced within a WSDL. 

Example extension dss-example-extension.xsd:

<?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"
           xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema"
           targetNamespace="urn:dss:myextension"
           xmlns:my="urn:dss:myextension"
           elementFormDefault="qualified" attributeFormDefault="unqualified"> 

    <xs:group name="mygroup">
        <xs:choice>
            <xs:element name="Test" type="my:TestType"/>
        </xs:choice>
    </xs:group>

    <xs:complexType name="TestType">
        <xs:sequence>
            <xs:element name="Value" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>

</xs:schema>
And then I needed a second XML schema just to redefine the DSS element _within the same DSS namespace_: dss-example-extension-redefine.xsd: 

<?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"
           xmlns:dsb="urn:oasis:names:tc:dss:2.0:base:schema"
targetNamespace="urn:oasis:names:tc:dss:1.0:core:schema"
           xmlns:my="urn:dss:myextension"
           elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:import namespace="urn:oasis:names:tc:dss:1.0:core:schema" schemaLocation="oasis-dss-core-schema-v1.0-os.xsd"/>
    <xs:import namespace="urn:oasis:names:tc:dss:2.0:base:schema" schemaLocation="oasis-dss-base-schema-v2.0-os.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:group ref="my:mygroup"/>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:redefine>

</xs:schema>


Which I can import within my WSDL via:

    <types>
        <schema xmlns="http://www.w3.org/2001/XMLSchema";>
            <import namespace="urn:oasis:names:tc:dss:1.0:core:schema"
schemaLocation="dss-example-extension-redefine.xsd" />
        </schema>
    </types>
I still get a warning during compilation, but at least it compiles and seems to work at runtime:
    src-import.1.1: The namespace attribute 'urn:oasis:names:tc:dss:1.0:core:schema' of an <import> element information item must not be the same as the targetNamespace of the schema it exists in.   line 9 of file:/home/fcorneli/dss-x/src/wsdl/dss-example-extension-redefine.xsd 


Still some points I worry about:
* this adds yet another getter that I have to check within my server-side implementation (already at 16 on the vanilla DSS Core 2).
* this "single inheritance" mechanism allows only one profile -in a clean way- at the same time. If you want to use -say 5 profiles- you have to create the "intermix" top-redefine XML schema yourself. This could become very ugly after a while I guess... 




But you surely won't
complain that there is a distinct parsing step to read a X.509
certificate within an XML message.
Of course I don't expect that an XML parser can parse ASN.1/DER, else it wouldn't be called an XML parser in the first place. :) 

However, I do expect my XML parser to parse my XML.



This comes with the
dis-advantage but avoids inter-dependencies between architectural layers. 
OK, I lost you here. What do you mean?


Kind Regards,
Frank.


On 01/29/2018 03:49 PM, Andreas Kuehne wrote:

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/>








--
Frank Cornelis
e-Contract.be BVBA
https://www.e-contract.be

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