RE: [dss] comments on DSS requirements

[Trevor Perrin <trevp@trevp.net>]

At 12:30 PM 7/22/2003 +0100, Pieter Kasselman wrote:

>Comment on comments in-line :)
>
> > -----Original Message-----
> > From: Trevor Perrin [SMTP:trevp@trevp.net]
> > Sent: 19 July 2003 23:29
> > To:   Nick Pope; Frederick.Hirsch@nokia.com; dss@lists.oasis-open.org
> > Subject:      RE: [dss] comments on DSS requirements
> >
>         <snip>
> > > >
> > > >
> > > > >----
> > > > >3.7.4
> > > > >
> > > > >We mention policy a lot and that can mean different things. Do we
> > mean a
> > > > >URI and the rest is out of scope,
> > > >
> > > > We now have "Implicit Parameters" (3.5.6 and 3.7.8), which are
> > > > things that
> > > > are selected just by which URI you access.  We aren't calling
> > > > these things
> > > > policies anymore, cause that was confusing.
> > >
> > >I am not sure whether we are throwing away too much by just ignoring
> > >"policies".  I think that we do need to have the concept of something
> > that
> > >defines the rules under which the signature is created / verified.
> >
> > According to the doc, there's an "Application Profile", and which
> > application profile is used is determined implicitly by which URI you
> > access the server at.
> >
> > So if the "Application Profile" defines all these rules (for example, EPM
> > could be an application profile, as would eNotary), and the URI determines
> >
> > the application profile, is that sufficient?
> >
>         [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/

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.

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.

(for example, an Applicaton Profile might allow each service to include a 
particular signed attribute in the signature, or not.  Then it would be an 
Implicit Parameter of each DSS service supporting the Application Profile 
whether it did this or not).

I agree this needs more discussion at the F2F though!

Trevor