Radical proposal for Vnext of XML Signature

1. Introduction

XML Canonicalization as the preprocessor for signature generation and verification has proved less than satisfactory.
- Let's consider replacing C14N with something designed specifically for this role
- With the benefit of hindsight wrt the problems that have been uncovered with the existing architecture.

What must be signed?
- In order to play the role of guaranteeing the integrity of a document
- The right way to address this is to look at infoset items and properties.
Here's a suggested set of things which must be covered:

Document Information Item
children, base URI, all declarations processed, version

Element Information Item
namespace name, local name, children, attributes, base URI

Attribute Information Item
namespace name, local name, normalized value, attribute type

Processing Model Information Item
target, content, base URI

Character Information Item
character code

Comment Information Item
content
Note in particular that no information about namespace bindings is required/involved here
- no prefixes, no namespace attributes, no in-scope namespaces.

The previous section doesn't really answer the question
- We need a byte sequence to digest
  - not a tree of abstract information items and properties
-- . That might be too easy an answer for some, and in particular it would be horribly inefficient wrt namespace names.
You could ia trivial answer
- Treat the infoitem/property story as a simple object model, and serialize per e.g. JSON
The alternative I think would be worth exploring would be a variant of XMill
- This would massively reduce the redundancy
- As well as possibly improving the quality of the digest produced

I think Ed Simon's attitude is correct here
- If fidelity of prefixes in content is an issue
  - Type-aware processing would be required to convert e.g. QNames and XPaths in content into an expanded-name form