[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]