[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] DSS Policy wise server Profile
Agree – good idea. From:
Carlos González-Cadenas [mailto: 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]