WG: [dss-x] SignaturePtr problems ...

Good morning Andreas,

 

isn't the technical prerequisite that the object (document or signature)

to which the WhichDocument attribute points to has an xs:ID?

 

As far as I see it, both structures (InputDocuments/Document and SignatureObject/Base64Signature)

are in the end derived from dsb:Base64DataType, which may have this xs:ID such that

some WhichDocument-attribute (either being xs:IDREF or xs:anyURI) can point to it.

 

BR,

  dh

 

 

 

 

 

-----UrsprÃngliche Nachricht-----
Von:  <> Im Auftrag von Andreas Kuehne
Gesendet: Montag, 21. Januar 2019 22:40
An: dss-x <>
Betreff: [dss-x] SignaturePtr problems ...

 

Dear colleagues,

 

sorry come up late with a statement contradicting my view from the call.

But looking at the code produced for WhichDocument attribute I realized

our view of the intention of tghis attribute is wrong:

 

    public DocumentBaseType getWhichDocument() {

 

The attribute does not point directly to an arbitrary (XML) document

holding a signature but it refers to an instance of InputDocumentType.

So my assumption is wrong, _it is_ an in-document reference!

 

So the SignaturePtr is _not_  capable of identifying a signature within

a SignatureObject/Base64Signature! This sounds reasonable if you think

of just one signature directly contained within the Base64Signature. But

e.g. XAdES this may not be true. This shortcoming also makes it unusable

for the intended replacement of a Peter's SignatureIdentifier.

 

An obvious solution would be to replace the Base64Signature (in

SignatureObject) by a 'SignatureAsDocument' of the type DocumentType.

This allows easy referencing, it would fix the relationship in cases

where the signature should be included directly in SignatureObject. It

also would allow to transport big (encapsulating) signatures as

attachments.

 

The original

 

   <xs:complexType name="SignatureObjectType">

      <xs:choice>

         <xs:element name="Base64Signature" type="dsb:Base64DataType"/>

         <xs:element name="SignaturePtr" type="dss2:SignaturePtrType"/>

      </xs:choice>

      <xs:attribute name="SchemaRefs" type="xs:IDREFS" use="optional"/>

   </xs:complexType>

 

would morph to

 

   <xs:complexType name="SignatureObjectType">

      <xs:sequence>

         <xs:element name="SignatureDocument" type="DocumentType"

minOccurs="0"/>

         <xs:element name="SignaturePtr" type="SignaturePtrType"

minOccurs="0"/>

      </xs:sequence>

      <xs:attribute name="SchemaRefs" type="xs:IDREFS" use="optional"/>

   </xs:complexType>

 

But, big drawback, would add another element even in the case of plain

vanilla 'one signature, one detached document' calls. Easy structures

for simple calls _and_ also supporting the complexity of XMLDSig isn't easy!

 

 

What's your view?

 

-- 

Andreas KÃhne 

phone: +49 177 293 24 97 

mailto: 

 

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