RE: [dss] comments on DSS requirements

[Pieter Kasselman <pkasselman@baltimore.com>]

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

For more details see in-line comments

Cheers

Pieter

> -----Original Message-----
> From:	Trevor Perrin [SMTP:trevp@trevp.net]
> Sent:	22 July 2003 18:51
> To:	Pieter Kasselman; dss@lists.oasis-open.org
> Subject:	RE: [dss] comments on DSS requirements
> 
> 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/
> 
	[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. 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.

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

> (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!
> 
	[Pieter Kasselman]  Unfortunately I can not attend the F2F, can we
discuss this on the next teleconference, or alternatively through a couple
of mail exchanges?

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


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com