compared with
Current by Lance Thompson
on May 10, 2013 16:04.


 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 1 changes. View first change.

  Proposed outline for Rec 14
 \\
  
 h2. PART ONE : Recommendation 14 on Authentication of Trade Documents by Means Other Than a (Manual) Signature
  
 # Introduction
 # Scope
 # Benefits
 # Recommendation
 \\
  
 h2. PART TWO : Guidelines on Authentication of Trade Documents by Means Other Than a (Manual) Signature
  
 # Introduction
 # Other options than signature
 # Use of other authentication methods
 # Definition and function of signature
  
 h3. Chapter 4. Definition and function of signature
  
  
 h5. Definition of Signature
  
 * Link between a person and a document.
 ** {color:4f6228}A signature is not self-standing{color}
  
 * {color:4f6228}Having the following functions:{color}
  
 h6. Function of Signature
  
 * {color:4f6228}Identification function (who controls;{color}
 * {color:4f6228}Evidentiary function{color}
 ** Depending on the legal implications can involve: integrity, consent/commitment, acknowledgment
 * {color:4f6228}Attribution (link between signature and signatory) / (link between signature to the content){color}
  
 These three functions are on a variable scale (there can be more or less of each of these inherent in each signature)
 * If a certain level of all three of these are correctly fulfilled, then authenticity can be achieved
  
 h5. Definition of electronic signature
  
 * {color:4f6228}Data in electronic form in, affixed to or logically associated with, a data message, which may be used to identify the signatory in relation to the data message and to indicate the signatory's intention in respect of the information contained in the data message.{color}
  
 An electronic signature should not be discriminated because of its origin. (but may be discriminated because of their intrinsic qualities).
  
 h5. Document authenticity (as opposed to signature of a moral/physical person)
  
 * Origin & integrity of the document (but does not necessarily look at the signatory)
 * Authenticity = quality of the document / data
 * Authenticity & integrity can be improved in the electronic environment.
 \\
  
 h3. 5. Requirement for signature on trade documentation
  
  
 h3. 6. Security of data: transmission, archiving, retrieval
  
  
 h5. *{+}Security of data{+}*
  
 * Access to data should be limited to intended parties
 ** Legal responsibilities of the parties involved
 ** Depending on the _{+}level of confidence{+}_ required by the transaction, parties' interests in the event of litigation should be protected
 * Depending on the _{+}level of confidence{+}{_}required, trusted third parties should guarantee the corresponding level of confidence.
  
 h5. *{+}Transmission of data{+}*
  
 * Whenever possible, use of international standards
 * In a bilateral exchange, the two parties should explicitly agree on the method of communication and the method of authentication.
 ** They should consider the _{+}level of confidence{+}_ required when establishing this agreement.
 * Minimal requirements for data transmission are presented in Annex 2 with the appropriate technological solutions.
 ** (These minimal requirements also aim towards promoting interoperability.)
 ** (Perhaps annex on standards & repository of solutions submitted.)
  
 h5. *{+}Archiving / retrieval{+}*
  
 * Must take into account archival duration period
 ** The technology used must be maintained during the entire period (or functional equivalent)
 ** Migration from one technology to another during archiving.
 * Archiving method must correspond to at least an equivalent _{+}level of confidence{+}_ as the authentication/signature method used
 * The method of archiving should be auditable (checking the reliability - whether it works or not; checking correctness of retrieved data, readability \[format used\]; & encompassing the functional aspects of a authentication which is being accepted between the parties ...)
 * Only authorized parties should be able to retrieve the data.
 * Possible use of third-party archiving solutions which take into consideration the above points.
  
 h5. *{+}Governments should create and maintain appropriate legislative frameworks{+}*
  
 * Governments should provide the private community guidance on this issue
 ** For B2G transactions, government should clearly explain the level of confidence required (via laws, guidelines or other...)
 * These legislative frameworks should be reviewed regularly (5 years?) in order to correspond to actual business practices
 * These legislative frameworks should ensure the acceptability in court of transmission methods, archiving processes, etc.
  
 h3. 7. Conduct of trade document review process
  
  
 h3. 8. Checklist for the creation of a legally enabling environment {color:c00000}(here or in annex A? or in a separate annex?){color}
  
  
 h3. 9. Checklist for functional requirements of digital evidence (integration of the work of the previous draft Recommendation 37 {color:c00000}\- here or in annex B? or in a sep{color}{color:c00000}arate annex?{color}{color:c00000}){color}
  
 \\
  
 h2. ANNEX A Examples of legally enabling environments for dematerialized transactions
  
 * Propose a template for submissions
 \\
  
 h2. ANNEX B Examples of technical solutions that allow the elimination a (manual) signature from trade documents
  
 Propose a template for submissions (perhaps different for each type of solution)
  
 Proposed organization of received solutions by typologies (based on UNCITRAL "Promoting Confidence" document)
 * digital signatures (encryption, PKI, ...)
 * {color:c00000}Communication methods (methods which allow data exchange and authentication is realized through the method of communication, ex. VPN, ...){color}
 * biometric methods
 * ID & password methods
 * scanned or typed signatures
 * {color:c00000}no signature methods (methods that allow dematerialization of trade documents with no authentication on individual data transfers){color}
  *Rec14 Annex B submission (technical implementations)*
 || Country || Date Submission \\ || Submitting Organism \\ || Link \\ ||
 | CEFACT \\ | 13/01/15 | Rec14 W.G. \\ | [http://www1.unece.org/cefact/platform/download/attachments/48563016/130115+AnnexB+submissions+request+letter.pdf] \\ |
 | \\ | 13/04/11 \\ | Rec14 W.G. (for ref) \\ | [http://www1.unece.org/cefact/platform/download/attachments/48563016/121214art+Bonneau+article.docx] \\ |
 | CH \\ | 13/04/11 \\ | Swiss Customs \\ | [http://www1.unece.org/cefact/platform/download/attachments/48563016/CH+130411+Rec14-AnnexB+submission.docx] \\ |
 | EU \\ | 13/04/02 \\ | Imprimerie Nationale (FR) \\ | [http://www1.unece.org/cefact/platform/download/attachments/48563016/EU+130402+Rec14-AnnexB+submission+FR+Imprimerie+Nal.pdf] \\ |
 | SE \\ | 13/03/20 \\ | Swedish Customs \\ | [http://www1.unece.org/cefact/platform/download/attachments/48563016/SE+130320+Rec14-AnnexB+submission.pdf] \\ |
 | \\ | 13/04/11 \\ | SWIFT \\ | [http://www1.unece.org/cefact/platform/download/attachments/48563016/SWIFT+130411+Rec14-AnnexB+submission.pdf] \\ |
 | | 16/04/13 SP(WCO) | IMO | [http://www1.unece.org/cefact/platform/download/attachments/48563016/IMO+Draft+resolution.docx&nbsp]; \\ |
 | | 05/03/13 LR(FI) \\ | UCP | Uniform Customs and Practice for the Uniform Customs and Practice for Documentary Credits UCP 600 (ICC Publication No 600). Is electronic variations are regulated by the ICC document entitled eUCP. The Supplement to the Uniform Customs and Practice for Documentary Credits for Electronic Presentation ("eUCP") supplements the Uniform Customs and Practice for Documentary Credits (2007 Revision ICC Publication No. 600,) ("UCP") in order to accommodate presentation of electronic records alone or in combination with paper documents. |
 | | 25/04/13 MS(CH) \\ | signage in cloud \\ | [http://whitepapers.technologyevaluation.com/landing/33545/digital-signage-in-the-cloud.html?utm_source=91277&utm_medium=Compliance+Guides+for+Manufacturers&utm_campaign=&tecreferer=_91277&userID=3376430&email=sorgetti@fiata.com&bp=1] \\ |
 | | 130326 RF(US) \\ | | http://www.lightbluetouchpaper.org/2012/12/14/authentication-is-machine-learning/ \\ |