OASIS ebXML Messaging Services TC

  • 1.  About notary function of intermediaries

    Posted 10-23-2007 11:31 
    As discussed during the last call I think a usefull function or role  
of intermedairy could be that of a notary. That is, it signs a  
payload received from party A and then sends it on to party B. By  
signing the payload the intermedairy confirms the payload as valid/ 
true, like a notary does in the real world. As such a document is  
regularly required by law it might be a usefull function in a  
messaging environment.

Regards,

Sander


  • 2.  RE: [ebxml-msg] About notary function of intermediaries

    Posted 10-23-2007 16:03 
    Hello Sander,

A similar concept is being discussed in the OASIS DSS (Digital Signature
Services) TC [1,2,3]. This builds on an existing DSS concept called
"signature gateways" [4].

The most practical way to provide this functionality seems to be a mechanism
to express the operations that are requested (such as signing, or
timestamping) as DSS requests, either on a per-message basis or as part of
the contract between sender, intermediary and (ultimate) recipient. That
way, ebMS 3.0 part 2 would only need a notation to express the particular
DSS operation requested and the message parts that the operation relates to,
on a per message basis or per contract. Products that implement ebMS 3.0
could provide the functionality by leveraging third party emerging DSS
products, which provide very rich functionality.     
 
The idea of the intermediary acting as trusted audit trail of message
exchanges is in OSCI 1.2 [5], which has a concept called "recording".  OSCI
intermediaries can keep "process cards" that have timestamped records of
when messages were received, forwarded, acknowledged.  There is a protocol
for retrieving these process cards from the intermediary.  

Pim  

[1]
http://www.oasis-open.org/committees/download.php/25293/EbXML-dss-requiremen
ts.doc
[2] http://lists.oasis-open.org/archives/dss-x/200710/msg00031.html
[3] http://lists.oasis-open.org/archives/dss-x/200710/msg00041.html
[4]
http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-SignatureGateway-spec
-v1.0-os.html
[5]
http://www1.osci.de/sixcms/media.php/13/osci-specification_1_2_english.pdf 



    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  Re: [ebxml-msg] About notary function of intermediaries

    Posted 10-31-2007 22:42 
    Hi Pim,

I took a quick look at the DSS group site and a presentation on it.  
Based on that presentation I think that DSS is more about the  
delegation of security functions. That is somewhat different then the  
notary function I meant. What I can imagine is an intermediairy that,  
like a kind of notary, also sets its signature to indicate the  
validity of the message content. To me that looks different from the  
DSS functionality.

However I think both type of intermediaries can be useful in certain  
scenarios. To me DSS will likely be an internal intermediairy within  
an entity and the notary external between two communicating partners.

During the calls we discussed this kind of functionality and whether  
this should be within the scope of ebMS. As this functionallity looks  
more to be on the business level than on the message level. Maybe its  
better to do this with multi-party collaborations and describe them  
using CPA's if possible.

Regards,
Sander



On 23 okt 2007, at 18:02, Pim van der Eijk wrote:

>
> Hello Sander,
>
> A similar concept is being discussed in the OASIS DSS (Digital  
> Signature
> Services) TC [1,2,3]. This builds on an existing DSS concept called
> "signature gateways" [4].
>
> The most practical way to provide this functionality seems to be a  
> mechanism
> to express the operations that are requested (such as signing, or
> timestamping) as DSS requests, either on a per-message basis or as  
> part of
> the contract between sender, intermediary and (ultimate) recipient.  
> That
> way, ebMS 3.0 part 2 would only need a notation to express the  
> particular
> DSS operation requested and the message parts that the operation  
> relates to,
> on a per message basis or per contract. Products that implement ebMS  
> 3.0
> could provide the functionality by leveraging third party emerging DSS
> products, which provide very rich functionality.
>
> The idea of the intermediary acting as trusted audit trail of message
> exchanges is in OSCI 1.2 [5], which has a concept called  
> "recording".  OSCI
> intermediaries can keep "process cards" that have timestamped  
> records of
> when messages were received, forwarded, acknowledged.  There is a  
> protocol
> for retrieving these process cards from the intermediary.
>
> Pim
>
> [1]
> http://www.oasis-open.org/committees/download.php/25293/EbXML-dss-requiremen
> ts.doc
> [2] http://lists.oasis-open.org/archives/dss-x/200710/msg00031.html
> [3] http://lists.oasis-open.org/archives/dss-x/200710/msg00041.html
> [4]
> http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-SignatureGateway-spec
> -v1.0-os.html
> [5]
> http://www1.osci.de/sixcms/media.php/13/osci-specification_1_2_english.pdf
>
>
> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content