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: dss-x@lists.oasis-open.org <dss-x@lists.oasis-open.org> Im Auftrag von Andreas Kuehne
Gesendet: Montag, 21. Januar 2019 22:40
An: dss-x <dss-x@lists.oasis-open.org>
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: 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