Re: [Fwd: [dss] More on EnvelopingSignature]

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Dear all,

Edward Shallow wrote:

[...] In fact one could
use either the ObjId passed in EnvelopingSignature or why not simply the
RefURI on the target BaseDocumentType to add the Id attribute to the newly
constructed ds:Object node (see Andreas' enveloping example on the Wiki ...
#content).

What if the InputDocuments RefURI is not a bare name XPointer (or equivalent).

1. RefURI="#...some...XPointer..."
2. RefURI="www.somehost.com/somelocation#...some...XPointer..."

If the input documents RefURI is 1. or 2. then an ID Attribute would have to be generated
(e.g. random name) for the ds:Object's Id attribute and the ds:Reference's URI, wouldn't it?
I'd rather leave the decision which name to give a ds:Object to the client.

In the case of a bare name XPointer (or equivalent) however I don't see a problem omitting
EnvelopingSignature's ObjId attribute.

An alternative would be to allow bare name XPointers (or equivalent to retain comments etc)
for the RefId only for enveloping signatures, however then the server could not retrieve external resources
and embed them as ds:Objects, even not in a profile.

I do not believe that the False scenario will present itself
often enough to be useful and is not IMHO warranted. Why would the user
create any signature-specific framing at all ?

I agree on that.

 That is what they want the
server to preform.
[...]

From: Trevor Perrin [mailto:trevp@trevp.net] 


Juan Carlos,

You make a good point: currently, there's no way for clients to use
<dss:EnvelopingSignature> and request a signature that references the
<ds:Object>.  Thus, the ObjId attribute is not very useful.

I propose that we eliminate the ObjId attribute.  Instead add an attribute
dss:EnvelopingSignature/@addObjectWrap=[true/false].

If true, the server adds a <ds:Object> around the input document when
embedding it, per the current text.
  

The server would still have to generate a value for the ID attribute if the RefURI is not a bare name XPointer
or the RefURI has to be a bare name XPointers (or equivalent to retain comments etc).

If false, the server assumes a <ds:Object> is already present in the inpout
document, so the server embeds the input document directly in the
  signature.
  

If this means one would receive the XMLData contents already surrounded by <ds:Object> Tags already
having ID attributes somewhere inside it's contents and the documents RefURI would have to match one ID
inside XMLData's content.

i.e. RefURI="#SomeID" or  RefURI="#xpointer(id('SomeID'))"

Still we should not forget that ID Attributes inside dss:XMLData's contents require a Schema or DTD for
the input Document to identify the ID attribute(s).

best regards

Konrad