RE: [dss] Namespace inheritance, other approach

["Edward Shallow" <ed.shallow@rogers.com>]

I guess the simple answer is "whole document validation". That is, some
arbitrary piece of crypto software creates a signed document (enveloped or
enveloping are most common) and they would like to send it to a service for
extened verification including: certificate path validation, revocation
status checking, timestamping, and maybe logging. In this scenario they want
to pass up the signed document as an entire artifact exactly as created by
the desktop tool/software. I won't mention any names but I know of at least
2 desktop XMLDSIG-enable applications which do this right now AND include
both <?XML ...> declaration lines and PI lines.

Ed


-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: May 19, 2005 2:19 AM
To: ed.shallow@rogers.com
Cc: dss@lists.oasis-open.org
Subject: Re: [dss] Namespace inheritance, other approach

Edward Shallow wrote:
> Folks,
> 
> This wholw tree and sub-tree discussion is fine, and I believe we are 
> getting closer to consensus. But please remember we still have 
> occassions where some form of encoding/escaping will always be 
> required (i.e. <?XML ...> declaration lines and PI lines which would 
> precede the root). This is the "whole document" scenario which we have 
> not outlawed and is a legitimate use-case. Hence the "encoding=" 
> attribute that we are contemplating that we borrowed from "ATOM" would 
> have to support, at a minimum 1) xml (the default perhaps), 2) escaped,
and 3) base64.

Could you give examples of why we need to put Processing instructions and
<?XML ...> lines in <dss:XMLData>?


Trevor