Re: [dss-x] Rewriting of imported schemes

[Andreas Kuehne <kuehne@trustable.de>]

Hi Frank,

> There seems to be an error in your rewritten xmldsig-core-schema. It
> can no longer validate XML signatures:
>
> cvc-complex-type.2.4.a: Invalid content was found starting with
> element 'ds:SignedInfo'. One of
> '{"http://www.w3.org/2000/09/xmldsig#":SignatureValue}' is expected.
>
the ds:SignedInfo MUST NOT show up. An XMLDSig signature is expected to
be contained within a dss:SignatureObject element. Where did you manage
to insert the signature?

Greetings,

Andreas
>
>
> Kind Regards,
> Frank.
>
> On 02/02/2018 01:33 PM, Andreas Kuehne wrote:
>> Hi all,
>>
>>
>> as agreed on the last call I did some research regarding the volume of
>> imported structures.
>>
>> XMLDSig & SAML:
>>
>> The blobification of signatures and timestamps in the core limits the
>> core's references to external types significantly. There are the SAML
>> schemes and XMLDSig. The latter provides especially
>> CanonicalizationMethodType and TransformType. Both contain all major
>> non-XML-syntax incompatibilities: xs:any, mixed content and a XPath
>> expression.  The 're-creation' of these types in a compatible way within
>> DSS-X core could be an option. The same is true for SAML.
>>
>>
>> XAdES:
>>
>> Considering the AdES or the Verification profile the XAdES schema is
>> included. It contains many structures and types that do not fit into the
>> multi-syntax approach. It even defines the most evil AnyType (sequence
>> of  xs:any and mixed content and an arbitrary set of attributes). It
>> also makes intensive use of the '<xs:choice maxOccurs="unbounded">'
>> pattern that does not fit very well with Java's schema-to-code compiler.
>> This pattern produces non-typesafe code like an xs:any. So the version
>> 2.0 design goals cannot be achieved with an unmodified XAdES schema. A
>> quick check with the code coverage of my DSS-X tests shows that at least
>> 50% (25 out of 50) of the structures defined in XAdES are used so
>> cherrypicking of the 'useful few' does not work out.
>>
>> Applying the blobification approach to the verification report sounds
>> promising  for the verification report if it will restricted to be
>> 'XML-syntax only'. This could be acceptable and the JSON syntax problem
>> do not apply. But the verification report itself is not a autonomous
>> artifact but uses the core schema. So we would introduce a mix of
>> multi-syntax-enabled types and XML-only parts. To me this sounds like a
>> concept that wiil be hard to understand for any DSS-X user.
>>
>>
>> My recommendation would be to keep things easy to use and consistent:
>> Support the multi-syntax paradigm everywhere and don't introduce
>> XML-only profiles! But this comes with price of rewriting of external
>> schemes.
>>
>>
>> Let's see what's Peter's view on JSON support for the verification
>> report. I wouldn't be surprised that team working with Javascript in the
>> browser and / or node.js in the server side would appreciate to see a
>> verification report in JSON.
>>
>>
>> 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