RE: [dss] comments on DSS requirements

[Trevor Perrin <trevp@trevp.net>]

At 11:08 AM 7/23/2003 +0100, Pieter Kasselman wrote:

>Hi Trevor, to summarise I think service location and service parameters
>(such as policy) are separate things. If we consolidate it in a single URL
>we need a clear convention on the interpretation of the URL or we need to
>pass the parameter to the service as an element in the DSS message (my
>preference). The latter solution is more flexible, and we can make it an
>optional parameter for the case where there is a single policy for a service
>or the case where the client is willing to use the default policy (whatever
>it may be).

This is what we had for a long time.  I thought there were some complaints 
and confusions, but yeah, we could go back to it.  Let's see what comes out 
of the F2F tomorrow.

[...]
 > >         [Pieter Kasselman]  By moving away from the explicit idea of a
> > >policy we are loosing flexibility in the system. The use of application
> > >profile is only a partial solution, for instance, a profiled service may
> > >offer multiple policies under which signatures can be
> > generated/validated.
> > >Thus by co-locating the application with the policy we are preventing the
> > >application from offering multiple policies under which signatures are
> > >generated/verified.
> >
> > Couldn't these just be different URIs at the same service?
> >
> > htp://dss.acme.com/highSecurity/
> > htp://dss.acme.com/mediumSecurity/
> > htp://dss.acme.com/lowSecurity/
> >
>         [Pieter Kasselman]  It depends on what you define as the service, is
>it htp://dss.acme.com or htp://dss.acme.com/highSecurity/ ? Which part of
>the URI represents the service and which part the policy? I would argue that
>htp://dss.acme.com/highSecurity/ is the service location, and now we are
>stuck with a static policy for that service.

I guess I think a static "implied parameters" for each service is okay.  I 
imagine that a company would host a very small number of DSS services, for 
particular uses, and you would just have to figure out which one is 
appropriate for your use and contact that.  Ie, someone would tell you 
"this is the code-signing service, this is the document-signing service, 
this is the time-stamping service, etc.."

The stuff with querying and policy identifiers and auto-discovering 
different services just seems a little too fancy.


>  This approach also prohibits
>the client from querying the service on its policies. If, for v5 (just
>making up a future version number) of DSS we have a way to express what is
>now described as implicit parameters, where does the client find the policy
>for the service located at htp://dss.acme.com/highSecurity/ ? In my view
>service location and service policy are separate things and by retaining
>that separation we increase the overall flexibility of our eventual
>solution. Naturally nothing prohibits the implementation of a static policy
>for a service if that is what is desired.

Sure, I'm just arguing against this on principle of keeping things simple.


> > What I like about this, is then client configuration is just a matter of
> > knowing the URI - i.e., a single piece of information.  If the client has
> > to access a URI *and* request a policy, then the user will have to fill in
> >
> > 2 text fields before accessing the service.  Even though it's the same
> > quantity of information, I think splitting it up and having people juggle
> > 2
> > things would be confusing.
> >
>         [Pieter Kasselman]  This is a specific implementation where you are
>assuming a specific kind of user interface (one where the user has to type
>parameters such as URI's). It is easy to imagine an interface where the user
>does not need to know a URI at all, just a service descriptor with a list of
>options (one of which would include policy). Explicitly splitting the
>service policy from the service location does not have to impact the
>usability, it may increase it.
>
> > That's why the current doc says the URI determines the application
> > profile,
> > and also other "Implicit Parameters" such as which key to sign with, what
> > certs and validation info to include, which signed/unsigned attributes are
> >
> > included, and anything else that the Application Profile allows to vary.
> >
>         [Pieter Kasselman]  The service location (the URI) and the service
>policy or behaviour are distinct from each other. It should be possible to
>configure the service to provide multiple policies or profiles, and it
>should be possible for the client to indicate which policy it prefers. I
>would even go as far as suggesting that the client should be able to query
>the service to determine a list of policies it supports (the policies may be
>returned with friendly names to augment the URIs to assist the client in
>selecting an appropriate policy). Call it policy discovery.


We had this at one point too!  You would have liked the doc more before I 
got carried away with cutting excess out of it :-)

>  Separating the
>policy from the service location has another advantage since it will allow a
>client to retrieve the policy itself (once we have a way to express policy)
>and inspect it / make a decision before selecting it.

I guess I just don't see the need for clients to automatedly discover or 
examine policies.  I assume some out-of-band channel will just tell you 
which DSS service to access for your particular need, and that'll be it.

Trevor