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] RE: ProcessingOptions example and discussion


Is we add Verify and Sign to the list of operations and include in Process
options which control the use of time-stamping applied to signed / verify
data, as I understand that you are suggesting, then I think we can meet the
use cases that I can envisage.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 05 September 2003 00:36
> To: Edward Shallow; 'OASIS DSS TC'
> Subject: RE: [dss] RE: ProcessingOptions example and discussion
>
>
> At 10:07 AM 9/4/2003 -0400, Edward Shallow wrote:
>
> >Not all of them. I agree with Trevor that 3) and 4) are more workable. 1)
> >and 2) are out of the question.
> >
> >In general, how a DSS implementation processes internally should be kept
> >from the user as much as possible. I believe 4) does this best. One is
> >typically performing a basic operation say "sign" ... applying a
> timestamp
> >is an adjunct activity. The primary verb is the sign, the
> request to have it
> >timestamped is a "ProcessingOption" or an "Options" sub-category as
> >suggested by Juan-Carlos.
> >
> >I guess I am agreeing with Trevor in that we should not hold up compound
> >operations as a notion deserving of it's own construct. It is simply the
> >impact of a particular "ProcessingOption". I believe we should allow
> >anything in the "ProcessingOptions" enumeration that makes sense from a
> >requester's standpoint. Simple booleans which fall into
> "Options" categories
> >will do the job.
>
> I agree with the above, at least wrt Sign-then-Timestamp: this
> can be done
> through the Signing protocol, as a boolean option or as part of a
> server's
> default behavior.
>
>
>
> >Please review my schema snippet.
> >
> >I really only like 4) if 3) means things like SignAndTimeStamp, or
> >VerifyAndUpdate, etc ...
> >
> >I can't see any example where the prime objective of the request does not
> >fall into one of our core protocol operations.
>
> What about VerifyAndUpdate?  Aka
> "VerifyThen[Sign/Timestamp/Refresh/whatever]".  Does it fall into the
> "Sign" or "Verify" core protocol, or is it a fusion of both?  To me, this
> is the big question..
>
> I would be happy to table this question until we've fleshed out
> the Signing
> and Verifying protocols.
>
> Are there other Compound Operations we need to consider?  Or would you
> agree that all compound operations are "adjunct activities" to
> the Signing
> and Verifying Protocols, except for Updating, which we're not
> sure about yet?
>
>
> Trevor
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
kgroup.php.






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