Re: [dss] dss_requirements_draft_10

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Trevor, 

See below:

> In fact, a signature 
>may be detached from some of its references, and enveloped or enveloping 
>with respect to others.

<JC>When you say that a signature can be enveloped "with respect to others",
I tend to think that you are not saying that the requester can request to
insert a signature
within more than ONE document....as this could mean that the SignedInfo in the
different instances of the Signature element could be different...
In my opinion we should not allow the server to insert the signature in
more than
one document.....
</JC>

>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.
>
<JC>Agreed</JC>

>
>
>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...."

<JC>Comment to the text by Tim: I am not very sure about  "Static aspects
of policy 
can be expressed in application profiles"... If the "policy" is a
"signature policy", I guess
that an application profile would claim alignment with a whole "signature
policy" by
means of an identifier pointing to its definition. </JC>
>
>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.
>

<JC>As I said before, an "application profile" could claim alignment with a
signature
policy -or perhaps allow select one among different ones?-. From my point
of view
the concepts are quite different. But also a signature policy is one thing
and the 
ETSI SIgnaturePolicyIdentifier is another thing. </JC>

>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?
>
<JC>Well, I guess that once the signature policies will be put in place, a
number of
them will be issued and identified. If a requester is forced by her
environment to 
use one, how she can be certain that the server generating the signature
has aligned
with that policy if everything is implied? She will have to know in advance
what signature
policies the server claims to align with? I think that allowing the
requester to optionally
ask for a specific signature policy would make sense. In the end those who
do not need,
will not use, an those that do need it will be able to be certain that
their request has been
satisfied without any previous or ulterior check: the mere response with a
signature will
mean that the server claims to have followed the rules of the signature
policy</JC>

Juan Carlos.

>
>Trevor
>
>
>You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
>