dss_requirements_draft_8

[Trevor Perrin <trevp@trevp.net>]

http://www.oasis-open.org/apps/org/workgroup/dss/download.php/2861/dss_requirements_draft_8.pdf
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/2860/dss_requirements_draft_8.doc

I'd been trying to squeak by making minimal changes, on the theory that 
most people weren't complaining, it was probably good enough, and a lot of 
text had been contributed by other people or debated over so I didn't want 
to disturb any precarious balances.  But it was becoming apparent that some 
things were totally unclear, our concepts no longer fit the organization, 
and spot changes had left it messier and messier.

So I refactored it substantially, and rewrote a number of parts.  I 
apologize for this so late in the game, but I think the result is a lot 
cleaner.  Please review, and make sure I didn't do too much damage..

Larger changes -

  - It assumes the Signing Protocol will be used for time-stamping.  I know 
Ed disagrees, but for the moment he's outvoted by me and a co-chair 
(congratulations Nick!).

  - Discussions of time-stamping and authentication were cut, as these 
didn't bear on the protocol but were of a tutorial nature summarizing 
different authentication methods (old 3.3.4) and time-stamping rationales 
(old 3.2.2).  I figured these were unnecessary, and this document should 
just focus us being a target for protocol design.

  - "Intended Audience" added per Tim's request

  - "Signing Policy" and "Verification Policy" were renamed "Implicit 
Parameters" with the text: "These parameters, and any others that aren't 
explicitly dealt with, are implicit in the URI at which the client accesses 
the server."  Calling them policies was a disaster.  Does this work?  On 
the con-call was there mention of something more WSDL-specific?

  - On the Verifying Request, there's a new "Request for Updated 
Signature", where the client asks the client to "update" the signature 
after verifying it by adding a timestamp, or validation info, or whatever, 
with the exact details determined by the "implicit parameters".  This was 
intended to subsume EPM Verify / ApplyPostmark, and the old 3.7.4 and 
3.7.5.  I know we're still thinking about this, but I wanted to put in 
something, even just a placeholder.

  - "Signature Verification Steps" added per Andreas and Juan Carlos' request

  - Notion of "profiles" was elaborated: "The request/response protocols, 
signature formats, and bindings, can all be profiled.  A combination of 
these profiles is an Application Profile that can be used to address a 
particular use case.  DSS server or client implementations will be 
compliant with particular application profiles of DSS, not with DSS 
itself."  Hopefully this clarifies the ways we were using the word.

Trevor