OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dss] DSS Policy wise server Profile


I think this approach is very sensible. I also suggest changing the word
"evidence" to "artifacts" to avoid collision in meaning with the term
"evidence" as used by law courts. Artifacts may be useful as evidence,
or not, depending on the digital evidence requirements of a particular
jurisdiction for an electronic signature. (A recent US 9th Circuit
Court of Appeals case has suggested that there are legal standards
under the Federal Rules of Evidence that must be met before submitted
digital evidence can be considered as such by a court.)

> -------- Original Message --------
> Subject: RE: [dss] DSS Policy wise server Profile
> From: "Nick Pope" <nickpope@secstan.com>
> Date: Thu, August 24, 2006 3:05 am
> To: 'Carlos_González-Cadenas' <gonzalezcarlos@netfocus.es>
> Cc: "'OASIS DSS TC'" <dss@lists.oasis-open.org>
> 
>                 
>  Agree " good idea.   
>  
>    From: Carlos González-Cadenas [mailto:gonzalezcarlos@netfocus.es] 
>  Sent: 23 August 2006 17:57
>  To: 'Nick Pope'
>  Cc: 'OASIS DSS TC'
>  Subject: RE: [dss] DSS Policy wise server Profile    Nick, All,   Im 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 Ive proposed early this year).   The needs Ive 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 theyre 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 dont 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, & Thats why Ive 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 youre 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). Ive 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 theres no time to do it now, we could consider the introduction of this issue in the DSS Issues Document for further consideration.    Best Regards, 
>  Carlos       -----Mensaje original-----
>  De: Nick Pope [mailto:nickpope@secstan.com] 
>  Enviado el: miércoles, 23 de agosto de 2006 16:26
>  Para: OASIS DSS TC
>  Asunto: [dss] DSS Policy wise server Profile   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]