[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: dss:SignatureObject and dss:Document asymmetry
Dear All, dss:Document allows to pass XML input documents in several ways, InlineXML, Base64XML and EscapedXML.
This design allows clients of the DSS
service to build requests using the better suited alternative for them, as
there are several implementation concerns (present in many common web-service
tools) when using the InlineXML alternative
So it’s ok to have
different alternatives, to let the developers choose the more appropriate to
their needs / tools. I was not present in the discussions related to the dss:Document design, but probably you
had these issues (or other similar) into consideration. Now, when dealing with the
other part, that is, XML signatures or XML timestamps (the binary (i.e. CMS) ones
are base64Binaries, no problem with that), we don’t have the same
facilities present in the dss:Document,
we only have an option: inline XML signatures/timestamps
(as we can only use dss:Base64Signature for binary (i.e. CMS) ones).
Apart from the design issue, this asymmetry adds practical
difficulties when generating signatures with data-binding tools
(common in the most common web-services toolkits (i.e. Axis, .NET, …). Obviously, I’m not against the inline
options, but there should be other options for pasting signatures inside the
request. IMO, we should have the same facilities present in the dss:Document element also for
signatures and timestamps. In other case, we’re almost forcing clients
not to use their common web-service toolkits, but to use low-level XML
manipulation toolkits (i.e. DOM level, cursor level or the like). In that direction, when
thinking about practical (schema) solutions for that, I’ve also observed
the extreme design overhead incurred by the dss:Timestamp
element: maybe you were looking to make explicit the two use cases for dss:SignatureObject: signature inside or timestamp inside. In
fact, the contents of dss:SignatureObject
(obviously, except the dss:Timestamp itself) could be
the same that the contents of dss:Timestamp (by now
an inline XML signature and a Base64Signature). So, we’re almost
duplicating dss:SignatureObject
contents into dss:Timestamp. Actually, the only difference
in their contents is that we don’t have SignaturePointers
for timestamps, but I don’t see any practical reason for not allowing enveloped
XML timestamps. My proposal (if I’m not
forgetting about something important, this solves the two issues at once):
Opinions? Best regards,
Carlos Gonzalez-Cadenas |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]