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] DSS-JSON binding

Hi all,

regarding Stefan's remark and my response:
I guess this is a (known) bug in the  JAXB implementation. 
as usual it turns out not to be a bug but a feature! Doing these two feature settings did the job:

        mapper.configure(MapperFeature.AUTO_DETECT_GETTERS, false);
        mapper.configure(MapperFeature.USE_ANNOTATIONS, true);

Why just a few elements showed the upper / lower case problem ... I don't know.

Nevertheless, I'm a bit concerned about the scope of the current effort. We discussed a broad range of topics. For now I would not focus on new signature formats( like JOSE) but on a core schema redesign. I took away from our last call with a version 2.0 of the core we try to achieve

  1. a streamlined core (Bauhaus instead of Baroque/Rococo). 
  2. minimized references to external schema
  3. a JSON binding

A more compact core can be achieved by unifying the different types of document / signature holders into a generic mechanism. This could be done by a base64 document holder and some kind of MIME type 'attribute'. Additionally this would open up opportunities to handle currently unsupported document and signature formats e.g. JOSE easily.

The effort to avoid external schemes will be harder to accomplish. Especially XMLDSig defines foundation structures of the core: ds:Transforms, ds:DigestMethod, ds:DigestValue and last not least ds:KeyInfo (assuming ds:Signature is hidden in base64 container). I have no bright idea how to get around these reference as I wouldn't consider it an option to copy'n'paste their content into the core. The situation is even worse with the profiles. E.g. the verification profile is using the XAdES schema intensively. Dtmo the XML world has the most mature and comprehensive set of schema definitions. So I would recommend to stick with these external schema references and find a way to transfer their definitions to other bindings (like the JAXB-bridging to JSON).

The JSON binding as the first non-XML-based binding makes it obvious that we mixed the transport and the payload representation in the core. A ds:Signature cannot be handled in JSON nativly. The mentioned approach of base64-containering will fix this issue.

In addition we took advantage of XML-specific mechanisms like xs:any. This is not supported by JSON (at least not out of the box). My current approach is to enumerate all types that may be included in e.g. OptionalInput. But this works for known sets of types only. OptionalInputs added by a new profile may cause problems. A variant of the base64 / MIME-typed container would do the job, but would leave the hard job of parsing to the implementer. Not an attractive option to me ... proposals welcome!

In addition I wold like to add some additional goals:

  • convenient use of the DSS interface for Java developers
  • consider other bindings (e.g. ASN.1)
  • low impact on the existing profiles

I would guess that most of the DSS implementers do use Java and love to work with a ready-made object model generated from some schema pre-compiler. Using some variant of an any-mechanisms leaves the coder with a binary blob to be parsed or a generic base class of the transport framework to narrow down. The (Un-)SignedProperties are a use case where this will occur often. This is not a design that enables anyone to build a reliable and well tested DSS client or server quickly. So I would vote for keeping an eye on usability for our dear (Java) programmers.

When considering a major rework of the DSS schema let's have a look at bindings for other stuff like YAML or ASN.1. I wouldn't want to work out committee draft documents but want to avoid any corner-cutting that may introduce problems later on.

Last but not least: If we happily redesign the core schema we may loose compatibility of many of the current profiles. How do we intend to deal with it? Contact the original profile authors and ask for an upgrade? Or just leave the DSS 1.0 world as it is?



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 

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