- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 3 Apr 2017 15:05:28 +0200
- 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>
- Message-ID: <CAKaEYhLpX47Q=9VbYhWkNJB5RCEhxiBoH5UvuXVbP8cp1gpKEw@mail.gmail.com>
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