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,


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:
And:


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> 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] Im Auftrag von Frank Cornelis
Gesendet: Freitag, 26. Januar 2018 15:16
An: 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; lineNumber: 1; columnNumber: 703; Unsupported binding namespace "http://annox.dev.java.net". Perhaps you meant "http://java.sun.com/xml/ns/jaxb/xjc"?
Had to remove:
    xmlns:annox="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; lineNumber: 1; columnNumber: 555; Unsupported binding namespace "http://annox.dev.java.net". Perhaps you meant "http://java.sun.com/xml/ns/jaxb/xjc"?
So had to remove:
    xmlns:annox="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; lineNumber: 23; columnNumber: 579; Unsupported binding namespace "http://annox.dev.java.net". Perhaps you meant "http://java.sun.com/xml/ns/jaxb/xjc"?
So had to remove:
    xmlns:annox="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; lineNumber: 1; columnNumber: 705; Unsupported binding namespace "http://annox.dev.java.net". Perhaps you meant "http://java.sun.com/xml/ns/jaxb/xjc"?
So had to remove:
    xmlns:annox="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 BVBA
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]