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

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/ )
>

Just looking through this spec, it looks completely broken:

For example lines like this :

"Identifier URLs MUST have null query and fragment values."

Make no sense.  Artificial restrictions that prevent interop and scaling.
Things like this are why decentralized identifiers in web 2.0 have been a
mess for over a decade.  Artificial and arbitrary restrictions not a good
idea.  A centralized registry of strings should generally be avoided.  Tho
in the browser (shopping cart) context, I can see why it could be OK.

Let's not make this kind of mistake.  Getting decentralized identifiers
right, will be a key competitive advantage, especially for block chains
which have strong dencentralized features.


>
> Decentralized Identifiers can be formatted as URL style or email style
> for example
>
> https://my.ledger.com/public_bitcoin_ledger/address
>
> or
>
> address@https://myledger.com/public_bitcoin_ledger
>
> or
>
> address@public_bitcoin_ledger
>
> 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
>
>