Hi,
Played some more with the new AnyType and new
OptionalInputsSignType. I discovered another interesting
side-effect of the new structure.
If the previous OptionalInputs contained n elements in a request
(DOM elements, or if JAXB recognized the type, JAXB elements), you
had to iterate over n items to know exactly what you received.
But because the new OptionalInputsSignType is an xs:choice, I can
no longer iterate over it in JAXB. I basically have to query
_every_ possible element's getter defined within the JAXB instance
to know what exactly it is that I have received to make sure that
I didn't receive an element that I don't support within my
implementation. For the moment thus, this forces me to query 16
getter methods.
This touches upon an interesting feature that is missing: a
mustUnderstand attribute.
If we look at two successful specs that provide extension
mechanisms, SOAP and X509, they both support a way to express
"importance" of an extension:
SOAP has the mustUnderstand attribute on Header child
elements
X509 has critical on the extension
DSS Core does not offer this feature, while it can be interesting
to be able to express this within the context of for example
critical security extensions.
This would lead to something like the following (so instead of
restricting, "opening" the extension points even further with a
maxOccurs unbounded on Optional element):
<xs:complexType name="Root2Type">
<xs:annotation>
<xs:documentation>
A new structure where you can express "must
understand" semantics.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="Optional" type="tns:Any2Type"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="Any2Type">
<xs:sequence>
<xs:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="mustUnderstand" type="xs:boolean"
use="required"/>
</xs:complexType>
Kind Regards,
Frank.
On 01/29/2018 10:02 AM, Frank Cornelis
wrote:
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.
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
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
--
Frank Cornelis
e-Contract.be BVBA
https://www.e-contract.be