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] Comments to draft 6 Use Case requirements


At 05:57 PM 6/17/2003 +0200, Gray Steve wrote:


>I thought I would submit the following requirements which are specific to
>the UPU's Electronic PostMark. I only received these yesterday from one of
>my technical colleagues. They may be useful for the Use case requirements
>document.
>
>
>·       Ability to tie multiple "business transaction" lifecycle events
>together under a common identifier or key. This will allow the complying
>service to tie together several significant events in the non-repudiation
>lifecycle.
>
>·       Ability to "store signed content" which would be awaiting pickup by
>an intended recipient. Additionally the ability to specify that the request
>to retrieve this content needs to be "signed" by the intended recipient
>(i.e. a "sign for pickup" facility)
>
>·       Ability to allow other trusted service providers to "vouch for
>events" in a given lifecycle. The example we most often use is the "Mail
>Transport Agent" vouching for the sender that he indeed submitted a
>document. Additionally the "Mail Transport Agent" can vouch to the EPM
>Service that it indeed transported the particular document. This can be
>accomplished by a "Vouched Event" operation. Chain of trust must be
>established between "vouching" and "vouched for" parties.
>
>·       Ability to allow a signator (acting as a sender) to request a signed
>delivery and  receipt confirmation from the recipient.
>
>·       Ability to add a timestamp to an existing signature presented by the
>subscriber.
>
>·       Ability to retrieve signature verification results, if authorized to
>do so.
>
>·       Ability to have "passed in" content checked by the service against
>the content (SignedInfo) of a previously created signature over that
>content. Essentially a check on the sameness of content previously signed.


Not to keep making work for you, but I'd love to see these demonstrated 
with use cases, so the rationale for these was clear.

Trevor 



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