[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: as usual it turns out not to be a bug but a feature! Doing these two feature settings did the job:I guess this is a (known) bug in the JAXB implementation. 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
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:
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?
Greetings,
Andreas
-- 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]