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] EPM use cases: some questions and one requeriment.


Dear Colleagues

I have attached a document where I have collated most of your questions
regarding the EPM use cases and provided answers. 

Please let me know if there are further clarifications required and I can
prepare something for discussion at Monday's telephone conference.

Regards


Steve Gray




-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net]
Sent: Saturday, June 21, 2003 3:10 AM
To: Juan Carlos Cruellas; dss@lists.oasis-open.org
Subject: Re: [dss] EPM use cases: some questions and one requeriment.


At 01:12 PM 6/20/2003 +0200, Juan Carlos Cruellas wrote:


> >In the first bullet of 3.6.2 it mentions a "policy" to be used for
> >Verification, which will be an identifier for some trust settings and
maybe
> >other parameters.  Maybe if we just add a way to indicate that
verification
> >information should be returned, we could leave it up to particular
policies
> >to control whether this means to return the references or the actual
> >validation information.
> >
> >I.e., just have the client pass a boolean to indicate whether he wants
> >verification data.  What type of verification data actually gets returned
> >would be determined by the particular server and policy.  This way we
don't
> >have to enumerate values for the different types of verification data,
and
> >worry about whether those values are complete for every type of
> >verification data one could come up with.  Would that work?
> >
> >Trevor
>
>Well as long as this policy (BTW, is the "policy" of 3.6.2 the
>policy of the server, the signature policy indicated by the client ?)
>that could be possible, but are we completely sure that such a policy
>will always be explicitly defined?

This was supposed to be the "Verification Policy", where 3.4.4 is the 
"Signing Policy".  These were intended to be identifiers that lump together 
any parameters that aren't explicitly covered elsewhere, with the idea that 
if the client doesn't identify a policy, each server has some default 
policy.  This isn't very clear, and "Policy" is an overloaded word, I'll 
try to clear this up in another draft in the next few days.

For things like what type of verification data to return, where there could 
be lots of different types and different ways of doing it (do you want 
certificates and/or revocation data or both?  do you want CRLs or OCSP 
responses or something else?  How recent do you need the verification data 
to be?  Does it need to be time-stamped?)  it seems easier to let the 
details of this be implicit in the Verification Policy, and just have the 
client say "yes, I want verification data", or "no, I don't".

Trevor 


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

EPM Use Cases Questions & Answers.doc



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