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

Re: Blockchain Standardization (was Re: PR for playground)

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Mon, 3 Apr 2017 15:05:28 +0200
Message-ID: <CAKaEYhLpX47Q=9VbYhWkNJB5RCEhxiBoH5UvuXVbP8cp1gpKEw@mail.gmail.com>
To: Mountie Lee <mountie@paygate.net>
Cc: Adrian Hope-Bailie <adrian@hopebailie.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials Community Group <public-credentials@w3.org>, Greg Adamson <g.adamson@ieee.org>, Timothy Holborn <timothy.holborn@gmail.com>, Blockchain CG <public-blockchain@w3.org>
On 3 April 2017 at 13:44, Mountie Lee <mountie@paygate.net> wrote:

> so the URI can be adaptable for representing identifiers
>

Yes.  This is for the use case of decentralized identifier standardization.


> but for the data format, we have no consensus.
>

Is an orthogonal topic.  Hopefully there is some consensus around reusing
linked data.

As for the "serialization" that tends to have subjective preferences, but
ultimately is not a deal breaker, as they are largely interchangeable.

I would rather look at the quality of the data, than the syntax.  Tho this
can have a correlation for unusual reasons.


>
>
> On Mon, Apr 3, 2017 at 7:32 PM, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On 3 April 2017 at 12:15, Mountie Lee <mountie@paygate.net> wrote:
>>
>>> personally I think turtle (https://www.w3.org/TR/turtle/) will cause
>>> confusing to represent ledger data.
>>> it has too much features than json.
>>> but also
>>> it has enough features to represent ledger data.
>>>
>>
>> Turtle and JSON-LD are more or less the same thing.  There is a one to
>> one mapping.
>>
>> Turtle is a bit more human readable tho.
>>
>> It also has an excellent upgrade path for advanced users, through TriG
>> (already standardized) and n3 which bring AI-like intelligence to the
>> declarative layer.
>>
>> But where turtle really shines is in the examples.  Almost all JSON
>> example I've found as a developer to be confusing and often containing
>> subtle errors or anti patterns.  Almost all examples I've seen in turtle
>> are easy, intuitive and in line with best practices.
>>
>> JSON is simply a fashion of web 2.0 which is thinking in trees, rather
>> than, thinking in graphs.  I'm equally comfortable with both, but the true
>> power of the web is when every node is a first class citizen.
>>
>>
>>>
>>>
>>> On Mon, Apr 3, 2017 at 4:21 PM, Melvin Carvalho <
>>> melvincarvalho@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 3 April 2017 at 09:05, Mountie Lee <mountie@paygate.net> wrote:
>>>>
>>>>> one important thing CG will disagree is
>>>>> no central registry of identifiers (even for ledger types)
>>>>>
>>>>
>>>> URI's a little bit centralized but not alot
>>>>
>>>> Each URI scheme will be registered with IANA and have a spec describing
>>>> how you introspect on that URI
>>>>
>>>> Specifications are always a form of centralization, but if written well
>>>> they can allow enough flexibility to take into account everyone's use
>>>> cases, and even those not yet imagined.  This is where a good
>>>> standardization process can create rich and scalable eco systems.
>>>>
>>>>
>>>>>
>>>>> for the message format JSON (including JSON-LD) is adaptable.
>>>>> but for content of message, still not sure "how"
>>>>>
>>>>
>>>> At a high level the serialization doesnt matter too much as many are
>>>> interchangable.  What you are doing in the data is creating a large graph
>>>> at the data layer of the web / internet, much as the web of documents spans
>>>> many different domains and affinities.  A block chain is special in a sense
>>>> in that it is largely domain invarieant (private / shared block chains
>>>> being a special case).  The well-known pattern is a great way to make URLs
>>>> domain independent.  What I think we have missing is an 'overlay network'
>>>> which links together all the public block chains.
>>>>
>>>> So, simply you have items like a block header, the block, the merkel
>>>> tree.  These are all data structures taht sit in documents and are linked
>>>> to each other, much like one block header links to another.  The trick with
>>>> linked data is to name things with URIs to enable this scalability.  After
>>>> all, a block chain is simply a type of linked data, hence the "chain".
>>>>
>>>> Similarly if you are describing a user or account you will want to tie
>>>> key values to those accounts.  That will make up your data structure.
>>>> Whether you use JSON or Turtle is probably your choice, tho Im sure it will
>>>> raise the usual debate in spec writing (actually, it's not too important).
>>>> There's also neat technologies like Linked Data Notifications which allow
>>>> new blocks to propagate and grow the chain.  I'd personally recommend
>>>> Turtle over JSON here as pretty much every example I've ever seen in JSON
>>>> is just confusing.  Turtle is a simple language that's human and machine
>>>> readable that can be picked up in a few hours, and gives you are real feel
>>>> of how linked data should work -- however, I suspect I'll lose that debate,
>>>> in any case turtle I have found very instructional :)
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 3, 2017 at 3:42 PM, Melvin Carvalho <
>>>>> melvincarvalho@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 3 April 2017 at 07:00, Mountie Lee <mountie@paygate.net> wrote:
>>>>>>
>>>>>>> at Web Payments WG had similar issue.
>>>>>>> and they published Payment Method Identifiers (
>>>>>>> https://www.w3.org/TR/payment-method-id/ )
>>>>>>>
>>>>>>
>>>>>> Thanks for the pointer.
>>>>>>
>>>>>> There's two types of decentralized identifiers.  One uses URIs to
>>>>>> great a giant network.  One is human readable, and should be mainly used
>>>>>> for display purposes or in (small) proprietary networks.  Web architecture
>>>>>> 101 says to use URIs, and those are the ones that should be standardized.
>>>>>>
>>>>>> Politics can also play a role here, but we should aim to minimize
>>>>>> that in the blockchain CG via appropriate pushback, in order to create
>>>>>> scalable block chain technology which is sorely needed.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Decentralized Identifiers can be formatted as URL style or email
>>>>>>> style
>>>>>>> for example
>>>>>>>
>>>>>>> https://my.ledger.com/public_bitcoin_ledger/address
>>>>>>>
>>>>>>
>>>>>> The de facto way to denote a document on the web.  Remember also that
>>>>>> documents contain data, just as files contain data.  This data can include
>>>>>> human readable or memorable identifiers too.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> address@https://myledger.com/public_bitcoin_ledger
>>>>>>>
>>>>>>
>>>>>> -1 Not a URI.  Should not be used as part of the global graph.  It is
>>>>>> not robust, it does not scale, and looks like a bit of a mess.  This is
>>>>>> more appropriate for a silo or proprietary system.  Or for a human readable
>>>>>> shortcut.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> address@public_bitcoin_ledger
>>>>>>>
>>>>>>
>>>>>> as above
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> regards
>>>>>>> mountie
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 3, 2017 at 4:24 AM, Melvin Carvalho <
>>>>>>> melvincarvalho@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2 April 2017 at 20:29, Adrian Hope-Bailie <adrian@hopebailie.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2 April 2017 at 04:19, Melvin Carvalho <
>>>>>>>>> melvincarvalho@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2 April 2017 at 04:19, Manu Sporny <msporny@digitalbazaar.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> bcc: Credentials CG
>>>>>>>>>>> cc: Blockchain CG
>>>>>>>>>>>
>>>>>>>>>>> Migrating this thread to the Blockchain CG mailing list as it's
>>>>>>>>>>> become
>>>>>>>>>>> more blockchain-y, than web payments-y or verifiable claim-y.
>>>>>>>>>>>
>>>>>>>>>>> For those that didn't see the start of this thread, it is here:
>>>>>>>>>>>
>>>>>>>>>>> https://lists.w3.org/Archives/Public/public-credentials/2017
>>>>>>>>>>> Mar/0023.html
>>>>>>>>>>>
>>>>>>>>>>> On 03/31/2017 11:25 PM, Adrian Hope-Bailie wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I am interested to hear from those of you involved what the
>>>>>>>>>>>> goals of
>>>>>>>>>>>> these [Blockchain Standardization] initiatives are?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I think the goals are different between the standards bodies, and
>>>>>>>>>>> personally, I find it very difficult to track everything going
>>>>>>>>>>> on at the
>>>>>>>>>>> moment as things are still very dynamic.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> So it's not just me!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> What are you trying to standardize?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've heard at least these answers to that question:
>>>>>>>>>>>
>>>>>>>>>>> * governance for each blockchain
>>>>>>>>>>> * decentralized identifiers
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I think we have to standardize decentralized identifiers, as
>>>>>>>>>> everything else is built on that.
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> I feel like a lot of the technical standardization work is riding
>>>>>>>>> the blockchain hype. It's big "S" standardization just for the sake of
>>>>>>>>> standards bodies not wanting to miss the boat.
>>>>>>>>>
>>>>>>>>> Somebody please tell me what an ISO technical committee is going
>>>>>>>>> to standardize wrt DLT and Blockchain. The ISO process is way too slow to
>>>>>>>>> be effective in such a fast developing area.
>>>>>>>>>
>>>>>>>>> IMO technical standardization it will be ineffective until it has
>>>>>>>>> a focused use case (like DIDs). Part of the reason Interledger has been
>>>>>>>>> successful is that it's not trying to standardize something broad like DLT
>>>>>>>>> it's focused on value transfer.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> We've been stuck on this topic for 10 years as everyone has their
>>>>>>>>>> pet favorite identity system.
>>>>>>>>>>
>>>>>>>>>> What is needed is a system that will interoperate, and we should
>>>>>>>>>> aggressively throw out identity systems on the criteria that cant be shown
>>>>>>>>>> to interoperate (which is most of them!) or have significant traction.
>>>>>>>>>>
>>>>>>>>>> The main problem I see is that people are fascinated by
>>>>>>>>>> overloading identifiers to do two (or three) different things.  This is
>>>>>>>>>> wrong.  Identifiers should be opaque.  The reason being that different
>>>>>>>>>> people will overload in different ways, and that leads to failure to
>>>>>>>>>> interoperate, and balkanization.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Actually I think the problem is interoperability in the various
>>>>>>>>> protocols used to resolve and discover addresses and services from an
>>>>>>>>> identifier/name.
>>>>>>>>>
>>>>>>>>> And crucially, the need for identifiers to be useful and
>>>>>>>>> accessible to humans.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Typically a human will never see their URI.  Inquisitive developer
>>>>>>>> types might dive into that, but not regular users.
>>>>>>>>
>>>>>>>> Tied to those URIs will be human readable labels, such as firstame
>>>>>>>> lastname (e.g. facebook) or email address (eg google), but neither of these
>>>>>>>> will be your unique URI, they will be artifacts of UI.  There is a trap
>>>>>>>> that is easy to fall into, which is to conflate the operation of the UI (ie
>>>>>>>> what a user types in), with the universal identifier used to create a
>>>>>>>> social graph.  This is a key limitation of web 2.0 systems such as OpenID.
>>>>>>>>
>>>>>>>> Each type of URI will have ability to lookup more information about
>>>>>>>> a user.  In HTTP this is well standardized with linked data.  Other systems
>>>>>>>> will need to popularize lookup systems, and grow a network effect around
>>>>>>>> that.  This is normally a lengthy process (years or decades).  HTTP URIs on
>>>>>>>> the other hand have the advantage of a large network, and well defined
>>>>>>>> lookup systems that are the most widely deployed on the planet.  So having
>>>>>>>> a good strategy for this kind of identifier will be critical.  That's not
>>>>>>>> to say that HTTP URIs are the only game in town, other types will gain
>>>>>>>> traction over time and they should all be able to play nicely together so
>>>>>>>> longs as specifications allow that to happen.
>>>>>>>>
>>>>>>>> I think for newer protocols it would be an advantage to standardize
>>>>>>>> ways to map them to HTTP URIs too.  This is sometimes done with the
>>>>>>>> "well-known" pattern.  One type I've been interested lately in, is ipfs
>>>>>>>> which seem to have a nice eco system for working with hashed content.
>>>>>>>>
>>>>>>>> Perhaps it's going to be possible to align ipfs and did identifiers
>>>>>>>> for the domain (decentralized) independent paradigm.  IPFS want to also
>>>>>>>> implement Linked Data so that could help interop.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The most logical thing to do is to start by saying
>>>>>>>>>> standardization of identities MUST be URIs.
>>>>>>>>>>
>>>>>>>>>> Then look at ecosystems within each URI scheme:
>>>>>>>>>>
>>>>>>>>>> For example
>>>>>>>>>>
>>>>>>>>>> http URIs have a perfectly good spec that is widely deployed
>>>>>>>>>> called WebID.  Alternatives in the http world can be proposed, but let's be
>>>>>>>>>> ready to standardize what makes sense.  I would recommend labeling any
>>>>>>>>>> identity system that relies on http 303 redirects as an anti pattern, as
>>>>>>>>>> experience has shown they are a nightmare to deal with, and also they mix
>>>>>>>>>> the data layer with the transport layer.
>>>>>>>>>>
>>>>>>>>>> bitcoin seems to have significant traction as a uri scheme and
>>>>>>>>>> fits into the anyURI category
>>>>>>>>>>
>>>>>>>>>> I think enough work has been done on DID URIs to merit further
>>>>>>>>>> investigation
>>>>>>>>>>
>>>>>>>>>> Of course mailto: and tel: URI schemes exist.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is a nice start but then there needs to be a standard
>>>>>>>>> discovery protocol per scheme.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes.  Well, only if you're going to use that scheme.  If you use
>>>>>>>> HTTP URIs the problem goes away.  A better question might be why you would
>>>>>>>> want to use something else?
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> We have a standard encoding for a Universal Resource Identifier
>>>>>>>>> and this has an allowance for a scheme so that we can define a different
>>>>>>>>> Universal Resource Discovery Protocol per scheme.
>>>>>>>>>
>>>>>>>>> We have at least one already: HTTP
>>>>>>>>>
>>>>>>>>> Assuming you have this, the final piece is a standard
>>>>>>>>> representation of a resource. i.e. If you give me a URI that you say
>>>>>>>>> identifies a person then when I use the appropriate discovery protocol for
>>>>>>>>> that URI scheme I should get back a resource I know how to interpret.
>>>>>>>>>
>>>>>>>>> (We're changing topic here again)
>>>>>>>>>
>>>>>>>>
>>>>>>>> I dont think this is too far off topic.  The purpose of a URI is to
>>>>>>>> create connections in a network.  The natural next step is, tying key value
>>>>>>>> pairs to those URIs allow user facing technology to hide the complexity
>>>>>>>> from the user and create web scale systems.  The sanest way to represent
>>>>>>>> those key value pairs is the existing standard of Linked Data, choosing
>>>>>>>> your preferred serializations (from experience I highly recommend turtle
>>>>>>>> for advanced users).
>>>>>>>>
>>>>>>>> Another option would be to create a proprietary representation, and
>>>>>>>> try to popularize that through standardization.  I'd recommend against
>>>>>>>> going down this route, as Linked Data is starting to gain decent traction.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Perhaps we should start a wiki page on identity, and lay out the
>>>>>>>>>> guidelines to achieve standardization.  This is the building block for
>>>>>>>>>> everything we do.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> * interledger transactions
>>>>>>>>>>> * interledger linking
>>>>>>>>>>> * standardization around Bitcoin/Ethereum
>>>>>>>>>>> * smart contracts
>>>>>>>>>>> * blockchain data models
>>>>>>>>>>> * HTTP APIs
>>>>>>>>>>>
>>>>>>>>>>> So, there is technical standardization and political governance.
>>>>>>>>>>> Our
>>>>>>>>>>> organization is most interested in the technical
>>>>>>>>>>> standardization, but I
>>>>>>>>>>> struggle to see any initiative that has drawn more than a
>>>>>>>>>>> handful of
>>>>>>>>>>> blockchain organizations to the table. Interledger seems to be
>>>>>>>>>>> the most
>>>>>>>>>>> far along. I think we're making progress for cross-chain
>>>>>>>>>>> decentralized
>>>>>>>>>>> identifiers (DIDs). The Linked Data Decentralized Ledger stuff
>>>>>>>>>>> is new,
>>>>>>>>>>> but I'm speaking at a workshop on the topic day after tomorrow
>>>>>>>>>>> in Perth,
>>>>>>>>>>> Australia and will have a better idea on what the industry is
>>>>>>>>>>> thinking
>>>>>>>>>>> wrt. traction at that point (I don't expect much traction at
>>>>>>>>>>> present).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> As I said above I don't see "blockchain" or "DLT" standardization
>>>>>>>>> happening soon. The industry is still figuring out the details and while
>>>>>>>>> there is still a feeling that there may be undiscovered opportunities
>>>>>>>>> around the next corner the prominent players are not going to fall over
>>>>>>>>> themselves to collaborate on a standard.
>>>>>>>>>
>>>>>>>>> And, for many in the industry the belief that a DLT provides
>>>>>>>>> interoperability is still widely held.
>>>>>>>>>
>>>>>>>>> Interledger is not a blockchain standardization effort. The
>>>>>>>>> amazing developments around value recording ledgers (like Bitcoin, Ripple,
>>>>>>>>> Ethereum) have provided the diversity of use cases to inspire a standard.
>>>>>>>>>
>>>>>>>>> In reality Interledger could have been developed to just work
>>>>>>>>> between traditional private ledgers but the desire to make it interoperate
>>>>>>>>> with public DLTs has been a key influence on the work.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> So Adrian, to give you a data point... I can't see anything
>>>>>>>>>>> clearly yet,
>>>>>>>>>>> but I know that we're going to be seeing more and more proposals
>>>>>>>>>>> for
>>>>>>>>>>> standardization over the next year and we'll see how those
>>>>>>>>>>> resonate with
>>>>>>>>>>> the community. I'm skeptical that we can do big "S"
>>>>>>>>>>> standardization and
>>>>>>>>>>> should instead be seeking little "s" standardization. I think
>>>>>>>>>>> things
>>>>>>>>>>> like Interledger, Chainpoint, decentralized identifiers, data
>>>>>>>>>>> models,
>>>>>>>>>>> and HTTP APIs are all we could suggest standardization proposals
>>>>>>>>>>> for at
>>>>>>>>>>> this point in time... and even then, they'll be rough for
>>>>>>>>>>> another year
>>>>>>>>>>> or three before we start to see some momentum. Just my $0.02.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Thanks Manu. With all this talk of standardization I worried that
>>>>>>>>> there was something I was missing. But it seems we're all in the same boat.
>>>>>>>>> Waiting to see where the tide takes this thing...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Adam, are you in Perth for WWW2017? Pindar and I will be there
>>>>>>>>>>> tomorrow
>>>>>>>>>>> along with Tim and a few other blockchain folks. Perhaps we
>>>>>>>>>>> could sit
>>>>>>>>>>> down and have a chat about what we see as reasonable things to
>>>>>>>>>>> pursue in
>>>>>>>>>>> the next year or two?
>>>>>>>>>>>
>>>>>>>>>>> -- manu
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu
>>>>>>>>>>> Sporny)
>>>>>>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>>>>>>> blog: Rebalancing How the Web is Built
>>>>>>>>>>> http://manu.sporny.org/2016/rebalancing/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mountie Lee
>>>>>>>
>>>>>>> PayGate -- Payment & Money Remittance Service
>>>>>>>
>>>>>>> Tel : +82 2 2140 2700 <+82%202-2140-2700>
>>>>>>> E-Mail : mountie@paygate.net
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mountie Lee
>>>>>
>>>>> PayGate -- Payment & Money Remittance Service
>>>>>
>>>>> Tel : +82 2 2140 2700 <+82%202-2140-2700>
>>>>> E-Mail : mountie@paygate.net
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Mountie Lee
>>>
>>> PayGate -- Payment & Money Remittance Service
>>>
>>> Tel : +82 2 2140 2700 <+82%202-2140-2700>
>>> E-Mail : mountie@paygate.net
>>>
>>>
>>
>
>
> --
> Mountie Lee
>
> PayGate -- Payment & Money Remittance Service
>
> Tel : +82 2 2140 2700 <+82%202-2140-2700>
> E-Mail : mountie@paygate.net
>
>
Received on Monday, 3 April 2017 13:06:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:36 UTC