Skip to end of metadata
Go to start of metadata

Non-Repudiation

Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement or contract.

Source: Wikipedia (accessed in April 2013)

DDEX messages convey, in effect, an extension or exhibit to the commercial contract between sender and recipient. It is therefore very important that the sender of a message knows that the message has arrived - and can prove that it has arrived. Equally, it is often important for a company to be able to show that he has not received a specific message. One  example where the benefit of having non-repudiatable messages are take-down notices sent from a label to a DSP:

  1. The sender needs to know that a take-down notice has been received by its down-stream partners to fulfil its legal obligation to, for instance, the artist that has requested the content to be taken down.
  2. Equally, if the content hasn't been taken down, the DSP would want to be able to show that label has not sent the take-down notice and, thus, the fault is not with the DSP.

 

DDEX's message exchange protocols support non-repudiation. When using web-services, non-repudiation is an essential part of the standard. However the FTP profile of the message exchange choreographies do not mandate the use of the acknowledgement messages. And it is these acknowledgement messages that deliver non-repudiation.

DDEX highly encourages implementers of the FTP-based message exchange choreographies to make use of the acknowledgements.

 

 

 

 

  • No labels

4 Comments

  1. Anonymous

    But how to make use of the ackonwledgements when using FTP/SFTP? 

    steven.xie@naxos.com

  2. Hi Stephen, please find an email in your inbox.

  3. Anonymous

    I have the same question. Why not post the solution publicly?