[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] DSS Policy wise server Profile
|
Nick, All, I’m
very interested in the “policy” issues regarding DSS protocol. By
now, we have identified several kinds of policies, like Service Policies
(included in DSS core) and Signature Policies (somewhat included in the policy
wise profile and in the XSS profile I’ve proposed early this year). The
needs I’ve detected so far regarding policies are *Clients
to instruct the server to act under some specific policy or policies (i.e. a
server policy only or a server policy and a signature policy). This can imply
passing the identifiers of the different policies or the entire policy
documents. *Clients
to ask the server to provide the policy or policies they’re operating
under. This can imply the server
returning identifiers of the different policies or the entire policy documents. When
I say that the server can operate under several policies, I don’t want to
express that a concrete request is going to be served under several service
policies. Of course, a request should be only served under a specific service
policy at a time (however, this does not imply that a concrete user has to
request always the same service policy). What
I want to express is that normally the policies are more or less a hierarchical
thing: you have one or more service policies, and each service policy could
allow the user to select different signature policies, cryptographic policies,
evidence policies, archival policies, … That’s
why I’ve introduced the concept of “sub-policy” some time
ago. The
semantics for that is as follows (this is the case for a client asserting
policies to a server): “ok, I want you to serve me under this “highly-reliable”
service policy, and I want to verify this signature under this specific
signature policy. The digital evidence policy you’re going to use when capturing,
managing and retaining evidences generated from the verification process is
this evidence policy…” However,
I agree that this are a pretty advanced usage, but I would like this “policy”
issue to be resolved in a consistent (not to have 10 optional inputs one for
each kind of policy) and extensible manner (different implementations can use
different kinds of policies, simple implementations
could even use no policies or only “service policy”). IMHO, our mission regarding policies in DSS core should be to establish a
framework that allow clients/servers to pass back and forth policy information
(as usual, profiles could define specific processing semantics for specific
kinds of policies). I’ve made a proposal in that direction in
one of my latest mails (point 4 of http://lists.oasis-open.org/archives/dss/200607/msg00020.html,
the schema should be extended if we also want to include entire policy documents,
not only policy URIs). I
would be in favour of eliminating this “Policy Wise Profile” if we consider
what to do with these policy issues. If there’s no time to do it now, we
could consider the introduction of this issue in the DSS Issues
Document for further consideration. Best Regards,
-----Mensaje original----- As
discussed at the recent TC meeting I talked to Robin Moses of Entrust regarding
interest in the Policy Wise profile and he indicated that at the moment his
company did not have specific interest in supporting this profile. Thus,
unless anyone indicates that they have an interest in the Policy Wise profile I
propose that it is not included in the set of profiles being considered in the public
review. If
there is anyone with any interest in this profile can they get in touch with
me. Nick |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]