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

I think we need to collect existing references
- Web Payments Payment Method Identifiers (
https://www.w3.org/TR/payment-method-id/ )
- Email Identifiers ( https://tools.ietf.org/html/rfc5322#section-3.4.1 )
- Docker Image Identifiers [registry_hostname[:port]/][user_name/](
repository_name[:version_tag] | image_id )

and have to set some policies to get consensus (followings are my
suggestion)
- decouple the id from domain or specific protocol (like HTTP)
- human readable and writable
- no central repository



On Tue, Apr 4, 2017 at 8:18 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

>
>
> On 2 April 2017 at 12:24, 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.
>>
>
> When I want to register on a new system it asks me to type in my
> identifier.
> I don't want to type in a URI.
>
> That is the usability problem that must be solved.
>
> If my identifier is mailto:adrian@hopebailie.com or tel:+12345678 then
> what do I type into the box labelled identifier?
>
> If the only use for the identifier was as a universal identifier for a
> social graph then everyone would use http URIs and the problem would be
> solved.
>
>
>>
>> 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?
>>
>
> Because I want something more usable (telephone number, email address,
> national id number) or I don't want to use the Web as my backing DB. I want
> to use a DLT for example.
>
>
>>
>>
>>>
>>> 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.
>>
>
> No, it is to identify resources. The purpose of a URL is perhaps closer to
> what you describe.
>
>
>> 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).
>>
>
> Actually I still think the next step is standardizing on a discovery and
> location protocol for each scheme otherwise we are stuck with HTTP only.
>
> Once we have a way to go from identifier to resource we can standardize
> the resource representation.
>
>
>>
>>
>> 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
E-Mail : mountie@paygate.net