- From: Orie Steele <orie@transmute.industries>
- Date: Fri, 10 Apr 2020 11:47:44 -0500
- To: Daniel Hardman <daniel.hardman@evernym.com>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAN8C-_LWfC0cV118o1sFqgXPNJ_zotk3NNi+EPqxJwjcYL6R9A@mail.gmail.com>
Daniel, I suspect that you may be frustrated that a large number of W3C members love working on web technologies, different communities have different priorities... This is the W3C. At this point I need to be blunt... constantly objecting to the standardization of Web and HTTP APIs for the VC Data Model and DID harms the adoption of DIDs and VCs by Enterprises and Governments, paying customers of many of the members of the W3C... We need HTTP and Web support for DIDs and VCs in order to ensure they are usable, today... we might also need gRPC, ZKPs, or JOSE... but we for sure need HTTP and Web. In terms of priorities, I believe HTTP and Web technologies are more important for the group to establish consensus and interoperability around first, because they already have significant investment from our (the communities) customers... We are in a post cloud era... companies have just finished investing millions of dollars in centralized IAM, VPC, migration from on-prem to cloud, integration of on prem and cloud... Microsoft, Google, Apple... all have cloud storage services, cloud based identity systems... public http APIs.... they are represented in the W3C, some of us are trying to support them, their browsers, and the millions of people who use their browsers. There is a difference between believing in gRPC and ProtoBuff's superiority and objecting to work items that use HTTP and the Web as a starting point.... and it's very frustrating for those of us who want to work together on HTTP and web technologies under the World Wide Web Consortium (W3C). DIDComm is being standardized at the DIF, I think that's probably a major reason why it's not actively discussed here... feel free to propose it as a W3C CCG work item, or https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential or https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof ... they appear to be dependent on DIDComm, but I'm sure there is a way to create a work item for VC Data Model over DIDComm in W3C and leave DIDComm in DIF.... assuming the IPR policy for aries-rfcs is compatible with such an approach. "Let's quit claiming that the asymmetric security model of standard HTTPS deployments is consistent with the decentralized ethos of DID-based security. " This is completely false and harmful to the DID and VC ecosystem. https://devcenter.heroku.com/articles/ssl-certificate-self "For apps with controlled distribution this warning can be avoided by creating your own authority certificate and adding it to your users’ browsers." Q: What is the difference between telling a browser to trust a certificate, and telling a person to trust a did / did method? A: Browsers support HTTP and Certificates, not DIDs and VCs. If we want browsers to support DIDs and VCs, attacking HTTP and Web Technologies is the last thing we should be doing. Please stop objecting to HTTP and Web Technologies, and work items at the W3C that attempt to prioritize support for these. Please create work items that reflect the things you want the group to focus on, and request that people contribute to those work items. Things that I know you care about that I would love to help contribute to that could be worked on in the W3C: - ZKP Proof Representations that work with ledgers other than Indy. - DIDComm over HTTP - QRCode / Offline / Compressed VC Representations If you have a work item which you want supported, feel free to email me or raise it on the W3C CCG call so we can discuss it. OS On Fri, Apr 10, 2020 at 10:42 AM Daniel Hardman <daniel.hardman@evernym.com> wrote: > Manu and Orie: > > The question isn't the theoretical definition or possibilities. It's the > mindset of the group. > > I have repeatedly tried to get the group to think beyond HTTP, and > encountered friction. If the group wants to adopt the broader definition, > that's fine. But let's really adopt it. Let's not say the scope is really > broad, but turn around and view most of our interesting topics (EDV, CHAPI, > polyfills, issuer API, verifier API) through HTTP lenses, as if it's okay > to have one standard for HTTP, and then we can get around to the other > transports later, or with separate standards. Let's quit proposing to > describe our standards with Swagger docs. Let's quit thinking that > synchronous request-response is adequate to model our interactions. Let's > quit ignoring Aries RFC 0036 and 0037, which provide a format-independent, > standards-compatible means to exchange credentials that is HTTP compatible > but not HTTP dependent. Let's quit claiming that the asymmetric security > model of standard HTTPS deployments is consistent with the decentralized > ethos of DID-based security. Let's quit treating DIDComm as an irrelevancy. > Etc. > > On Fri, Apr 10, 2020 at 9:26 AM Orie Steele <orie@transmute.industries> > wrote: > >> +1 If you want to see a demo of a progressive web application, which can >> be installed on your mobile home screen, works offline, and uses a camera >> to scan QR Codes, and can sign and verify see: >> >> https://did-key.web.app/ >> >> I've been experimenting with using service workers to intercept requests >> for webkms, so that webkms can be run fully in browser, with software >> isolation for keys... it's totally hacky, but gives you an idea of just how >> powerful PWAs can be: >> >> https://github.com/OR13/react-pwa >> >> And here is a P2P implementation of the Game of Go, built with OrbitDB / >> IPFS / WebRTC... >> >> https://g0.or13.io/ >> >> Using Web RTC Rendezvous servers are particularly interesting to consider >> wrt VCs / DIDs... because you can show up on a web page (as is the case >> with the go demo), announce yourself as an identifier, and then >> immediately switch to e2e encrypted communication between peers... I don't >> have a demo of that with dids, but it's on my weekend project list for a >> couple months... >> >> OS >> >> >> >> >> >> >> >> On Fri, Apr 10, 2020 at 10:06 AM Manu Sporny <msporny@digitalbazaar.com> >> wrote: >> >>> On 4/10/20 10:31 AM, Daniel Hardman wrote: >>> > Should we understand by this that presenting credentials via QR code, >>> > via BlueTooth/NFC, via sneakernet, and so forth is out of scope? >>> >>> I'll note that Web-browsers can get access to the camera phone and scan >>> QR Codes: >>> >>> https://github.com/schmich/instascan >>> >>> and Web Bluetooth is released in many of the latest/popular browsers: >>> >>> https://caniuse.com/#feat=web-bluetooth >>> >>> ... and WebNFC just went into Origin trials in Chrome: >>> >>> >>> https://developers.chrome.com/origintrials/#/view_trial/236438980436951041 >>> >>> There continues to be confusion around the colloquial use of the word >>> "Web", which among developers, is mired in the historical protocol that >>> spawned the Web -- HTTP. The colloquial use is often outdated and wrong. >>> >>> The W3C is about the "Web Platform", which is not limited to HTTP. >>> Wikipedia has a decent definition here: >>> >>> https://en.wikipedia.org/wiki/Web_platform >>> >>> ... but here are the other protocols that are not HTTP that are viewed >>> as being part of the Web platform: >>> >>> * TLS >>> * Geolocation (and by extension, the Global Positioning System, >>> protocols and data formats) >>> * Web Sockets (which are not HTTP!) >>> * Web Of Things (IoT, CoAP, etc.) >>> * WebRTC (and a whole bunch of IETF specs on signalling >>> and media encoding/transmission protocols) >>> * Web Bluetooth (Bluetooth and its data formats and protocols) >>> * NFC (again, data formats and protocols) >>> * Media Capture API (audio and video formats and protocols) >>> >>> The W3C is not solely about HTTP, and you learn that pretty quickly when >>> you go to a W3C Technical Plenary, or participate in various standards >>> groups at W3C. I understand that it's difficult for many to participate >>> in that way. Fundamentally, the Web Platform is a bridging technology, >>> connecting all of these disparate data formats and protocols into a >>> cohesive application development environment. >>> >>> So communication of Verifiable Credentials over NFC, Bluetooth, WebRTC, >>> Web Sockets, QR Codes... IMHO, all very much in scope. >>> >>> -- manu >>> >>> -- >>> Manu Sporny - https://www.linkedin.com/in/manusporny/ >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: Veres One Decentralized Identifier Blockchain Launches >>> https://tinyurl.com/veres-one-launches >>> >>> >> >> -- >> *ORIE STEELE* >> Chief Technical Officer >> www.transmute.industries >> >> <https://www.transmute.industries> >> > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
Received on Friday, 10 April 2020 16:48:11 UTC