dss_requirements_draft_10

[Trevor Perrin <trevp@trevp.net>]

http://www.oasis-open.org/apps/org/workgroup/dss/download.php/3067/dss_requirements_draft_10.doc
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/3068/dss_requirements_draft_10.pdf


Changes:
  * Rewrote Signature Placement
  * Added All or Nothing on Requests for Signature Contents (see 3.5)
  * Added "Request Identifer" for correlating requests/responses
  * Added list of Profiles we intend to support (see 3.1.2)
  * Added "Claimed Identity" on Signing Request
  * Added "Requested Signing Key" on Signing Request
  * Added "Request for Transformed Data" on Signing Request
  * Mentioned that "Requestor Identity" can be a role as well as a name
  * Mentioned that requested signature attributes can be type/value, or 
just type (see 3.5.6)
  * Mentioned that Profiles can be extended as well as profiled (see 3.11)
  * Removed Output Delivery
  * Removed Transform Profile Identifier


I'd like to draw attention to a couple things:

The "3.5.2 Signature Placement" section now says a signature can be
  - Detached, Enveloped, Enveloping, or
  - Stand-alone

In the first 3 cases, the signature is inserted in one of the input 
documents, and the response contains the document *and* signature.  In the 
second case, the response is purely a signature.

The point is that a "detached" signature may still be part of an input 
document.  "Detached" in the XML-DSIG sense just means the signature is 
neither a child nor parent of any of its references.  In fact, a signature 
may be detached from some of its references, and enveloped or enveloping 
with respect to others.

So the real distinction is between a signature that's inserted into an 
input document, and a "stand-alone" signature, where a stand-alone 
signature is also detached, but a detached signature isn't necessarily 
stand-alone.  If this makes any sense..

What this precludes is the ability to say "this is an enveloped signature 
that will be inserted here", but return it stand-alone.  I.e., we're only 
allowing stand-alone detached signatures.  But that's what we agreed on at 
the meeting.



The issue of "policies" is still confusing.  Tim's minutes for 5.3 use the 
term in a way I think is dangerous:

"There was discussion of policies and how they would be associated with
services and operations.  The policy discussed here is what ETSI would call
a signature policy.

Policies can be implicit in the identity of the end-point to which the
request is sent.  Static aspects of policy can be expressed in application
profiles.  Then there are options within a profile.  For the time-being, we
will just allow policy to be represented by an identifier; we won't specify
any elements of policy.  If the policy is implied by the service URI, then
the policy indicator does not have to be used...."

I think the ETSI SignaturePolicyIdentifier is a very specific signed 
attribute, which we shouldn't confuse with our notions of an "Application 
Profile", or of "Implicit Parameters".  There may be a 1-to-1 relationship 
between Application Profiles and ETSI SignaturePolicies, there may not be.

I believe we decided to just let Application Profile be an Implicit 
Parameter?  I.e., which Application Profile you use depends on which 
service you contact?

Did we want to allow the client to request which SignaturePolicyIdentifier 
to use?  I would prefer to leave it implicit, but the group might've 
decided to put it in.  If so, is 3.5.6 sufficient to cover that?


Trevor