Re: [dss] dss_requirements_draft_10

[Trevor Perrin <trevp@trevp.net>]

At 11:48 AM 7/30/2003 +0200, Juan Carlos Cruellas wrote:
>Trevor wrote:
> >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>

What's the difference between a "signature policy" and an ETSI 
SignaturePolicyIdentifier?  Or rather, what's a signature policy?

In the requirements doc there's "signature profiles", is that what you 
mean?  Not to be pedantic, I'm just wondering if "signature policy" is an 
ETSI term or something.



> >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?

Because she's told which URL to use for that policy/profile/whatever.

>  She will have to know in advance
>what signature
>policies the server claims to align with?

Yeah.  I think we want loosely-coupled clients and services where the 
client request is "I want this and this and this signed", but the client is 
pretty hands-off about how the signing actually happens, and what type of 
signature is produced.  Otherwise, configuring clients and services to 
interoperate will be a lot of work, if you have to configure the client 
"request this profile, and this policy, and this SignatureMethod, and so on"..

>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:

Yeah..  the problem with adding options is that people *will* have to use 
them, even when they don't need to.  Servers will require them, and toolkit 
implementors will feel compelled to support them, and applications will 
display GUIs for managing them on the off-chance that a user might want to 
configure them, and users will feel inadequate if they don't configure 
those fields with something..

I guess it doesn't hurt much to add these things, but there is *some* cost 
to every option we add, I guess is my only point..

Trevor