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

 


Help: OASIS Mailing Lists Help | MarkMail Help

id-cloud message

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


Subject: Draft of business document variant of use case now labelled 9 (?)involving cloud digital signature "services"


Roger Bass and I have previously discussed some variations of this use case in discussing OASIS ebMS conformance profile AS4 and the OASIS BDX TC using intermediaries.

This description generalizes a bit from either of those variants. The attached file has the use case format style I hope.

 

This use case draft is intended for discussion at the Friday group that is concerned with filling various gaps in use cases in preparation for the gap analysis between use cases and current security specifications.

Description / User Story

Cloud message stores or cloud transfer intermediaries operating in a back-to-back user agent mode may act as security service intermediaries during the exchange of digitally signed business documents.

 

·            Intermediaries can provide services promoting the semantic alignment of exchanged data despite variations in protocols, syntax, versions, and security formats and tokens between the original sent and the converted message received.

·            Digital signatures are tied to the particular octet stream of the original, and conversions almost certainly will modify that octet stream so as to preserve semantic alignment in new syntactical forms and versions.

·            Sender and Receiver may not agree in their Certificate Authority Trust anchors, and may not be able to perform a useful authentication of the signed document.

·            Intermediaries will not in general be able to resign the hash of the converted message, nor will the originator in general be able to assess the semantic alignment of the converted payload.

·            The private signing keys of originators will not (and should not) be made available to intermediaries.

·            The security formats of the originator may be in one style (such as S/MIME) while those of the receiver may be restricted to XML Digital Signature.

·            The intermediary is in a position to sign the message using a receiver admissible format.

·            The intermediary can vouch for the identity of the sender that it has authenticated.

·            These services, and others, can facilitate secure interoperable semantically aligned business document exchange and acknowledgement.

 

 

 

 

Cloud signing services.docx



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