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

one important thing CG will disagree is
no central registry of identifiers (even for ledger types)

for the message format JSON (including JSON-LD) is adaptable.
but for content of message, still not sure "how"



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
E-Mail : mountie@paygate.net