W3C home > Mailing lists > Public > public-interledger@w3.org > April 2017

RE: Standards in Smart Contracts

From: Paul Ferris <pferris@objectchain.com>
Date: Tue, 18 Apr 2017 17:25:28 +0100
To: 'stéphane canon' <stephane.canon@scarlet.be>
Cc: "'Adrian Hope-Bailie'" <adrian@hopebailie.com>, "'Michiel de Jong'" <michiel@ripple.com>, "'Andrew Bransford Brown'" <andrewbb@gmail.com>, "'Interledger Community Group'" <public-interledger@w3.org>
Message-ID: <0d1b01d2b860$65c387d0$314a9770$@objectchain.com>
Hi Stephane

As you point out, other specifications and the work involved are way ahead of the brand new TC307  -  which is bad & good.  Bad that a great deal of fundamental work needs to be done for DLT, good that there is much to learn from work done in other contexts.  Certainly, there is the appetite to share and collaborate from the ISO delegates.  A quick description of your learning re: UML - RDF/OWL would be very much appreciated.

 

Here is a list of liaisons already set up (more are proposed, but may not have been established as yet)

 

Liaison Committees to ISO/TC 307


Reference

Title

ISO/IEC


 <https://www.iso.org/committee/45020.html> ISO/IEC JTC 1

Information technology

ISO/IEC


 <https://www.iso.org/committee/53186.html> ISO/TC 154

Processes, data elements and documents in commerce, industry and administration

ISO


 <https://www.iso.org/committee/54158.html> ISO/TC 184/SC 4

Industrial data

ISO


 <https://www.iso.org/committee/629121.html> ISO/TC 262

Risk management

ISO


 <https://www.iso.org/committee/5259148.html> ISO/TC 292

Security and resilience

ISO

Liaison Committees from ISO/TC 307


Reference

Title

ISO/IEC


 <https://www.iso.org/committee/45020.html> ISO/IEC JTC 1

Information technology

ISO/IEC


 <https://www.iso.org/committee/45306.html> ISO/IEC JTC 1/SC 27

IT Security techniques

ISO/IEC


 <https://www.iso.org/committee/629121.html> ISO/TC 262

Risk management

ISO

 

Hope this helps

Best regards

 

Paul Ferris

 

 

From: stéphane canon [mailto:stephane.canon@scarlet.be] 
Sent: 18 April 2017 16:36
To: pferris@objectchain.com
Cc: Adrian Hope-Bailie; Michiel de Jong; Andrew Bransford Brown; Interledger Community Group
Subject: Re: Standards in Smart Contracts

 

Thanks Paul,

 

I assume one of the discussions must be on the specification approach. I’ve been involved in the development of ISO20022 using UML. For multiple reasons, RDF/OWL would be a better choice than UML.

Is the idea to develop a « smart contract » standard or to develop a set of rules and conditions to be met to have valuable « contracts »? To be « trusted », some kind of process would be required to negotiate, approve and store the contract definitions. Existing processes (eg. ISO20022) are very rigid. The nature of BlockChain/DLT is asking for something moe flexible, more open… and free…

 

Regards,

Stephane

 

 

Le 18 avr. 2017 à 16:09, Paul Ferris <pferris@objectchain.com> a écrit :

 

Hi All

Sorry to crash into this list, but I have been a good listener for many months and I thought I could contribute a little, especially regarding standards (for what it’s worth).

 

We have just completed the first international meeting of ISO for standards in blockchain and DLT (or in ISO parlance, TC3017).  Discussion among the 70-odd international delegates was informed by pre-work contributed by one of the widest groups of countries that have ever adopted a new standards process for a new technology area.

 

And yet, the discussions in the area of smart contracts hit some very early problems.  Even the term “Smart Contracts” was a specific item of discussion, with some lawyers and others proposing they are neither ‘smart’ (in the legal world) or ‘contracts’ (in either legal or technical worlds).   The meeting resolved to kick off a study group (termed: ISO/TC 307/SG 5) to coordinate development in this area.

 

Of course, I’m not suggesting that standards are only standard when some international body reaches consensus between national delegates; standards are often created by good practice, and perhaps underpinned by W3C for instance.  But even here, I’d say we are some way off reliable standards in this area.  

 

Nevertheless, developing processes and definitions (such as spoken about here) and other aspects of smart contracts so that ‘good practice’ can be assumed, will (in my opinion) require good coordination between a number of specialist areas; certainly technology (coding) and law, but others too.  If this group decided to contribute by establishing a separate mailing list, and if the list became successful, I would be happy to coordinate to establish an official “Organization in liaison” between Interledger and the ISO processes in this area.  There is already coordination between W3C and ISOTC307, even at this early stage.

That way, in or out of scope of Interledger, we could make sure everyone has a voice and help solve problems more rapidly.

 

I hope I haven’t overstepped the mark with my rather lengthy contribution, just happy to help if I can.

 

Paul Ferris

 

 

 

From: Adrian Hope-Bailie [ <mailto:adrian@hopebailie.com> mailto:adrian@hopebailie.com] 
Sent: 18 April 2017 13:07
To: Michiel de Jong
Cc: Andrew Bransford Brown; Interledger Community Group
Subject: Re: Promise App

 

> Maybe it's worth creating a separate mailing list that discusses topics more around 'Conversations for Action' (promises, offers, etc.), and keep this mailing list strictly about Interledger?

Not a bad idea. I am surprised by the lack of coherence around standards for "smart contracts" and this probably fits in that category. Do any of the other W3C folk on this list know of any CGs addressing this kind of thing?

 

On 18 April 2017 at 10:58, Michiel de Jong < <mailto:michiel@ripple.com> michiel@ripple.com> wrote:

Hi Andrew,

 

Thanks for your post - I totally agree with you that it's important to understand the terminology around 'promise', 'want', 'offer', 'terms', and 'counter' that lead up to a payment.

 

However, this community group was created for discussing Interledger, and its scope is therefore limited to payments, and the ledger transfers involved in making these payments work across ledgers (hence the name "inter"-"ledger").

 

'Why' a payment occurs, 'how' the two parties agreed on the payment amount, 'what' service or goods the payment is for, and even whether it's an up-front payment (creating a debt) or an afterwards payment (resolving a debt), is out of scope.

 

I recently added a glossary to the RFCs repo, which might be of interest:  <https://github..com/interledger/rfcs/blob/master/0019-glossary/0019-glossary.md> https://github.com/interledger/rfcs/blob/master/0019-glossary/0019-glossary.md - as you can see, it only discusses terminology surrounding Interledger payments.

 

Do you think Interledger should describe more than just payments? Personally, I think it would make the scope to broad.

 

Maybe it's worth creating a separate mailing list that discusses topics more around 'Conversations for Action' (promises, offers, etc.), and keep this mailing list strictly about Interledger?

 

What do others think?

 

 

Cheers,

Michiel.

 

On Mon, Apr 17, 2017 at 12:18 AM, Andrew Bransford Brown < <mailto:andrewbb@gmail.com> andrewbb@gmail.com> wrote:

Understanding adversarial contract disputes and resolution:

 <http://34.208.7.206/ContractsPage.aspx> http://34.208.7.206/ContractsPage.aspx

 
Received on Tuesday, 18 April 2017 16:26:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 18 April 2017 16:26:37 UTC