- From: Adrian Gropper <agropper@healthurl.com>
- Date: Tue, 04 Apr 2017 02:19:03 +0000
- To: Adrian Hope-Bailie <adrian@hopebailie.com>, Mountie Lee <mountie@paygate.net>
- Cc: Blockchain CG <public-blockchain@w3.org>, Greg Adamson <g.adamson@ieee.org>, Manu Sporny <msporny@digitalbazaar.com>, Melvin Carvalho <melvincarvalho@gmail.com>, Timothy Holborn <timothy.holborn@gmail.com>, W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANYRo8iVrg=Ta=_DD6At7BM4BSwdAHg4BQHVdOozx2=pn0+zQA@mail.gmail.com>
We're using WebFinger to dereference an email address into a URI for either a DID or an UMA Authorization Server. Either one could be self-sovereign. Not sure it's a good solution, but it's all we've got. Adrian On Mon, Apr 3, 2017 at 9:34 PM Mountie Lee <mountie@paygate.net> wrote: > 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/2017Mar/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 > > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
Received on Tuesday, 4 April 2017 02:19:51 UTC