RE: Different Verifiable Credential protocols? (was: Re: Please vote to approve/disapprove the new charter)

Allow me a response and please excuse me if it sounds harsh,  this is not my intention. 

 

Claiming that Hyperledger Indy has a “broader remit”  than the CCG, which “focuses on the web”, sounds a bit strange to me. The all ZKP, and all blockchain, nature of Indy makes it less than ideal for many applications.  Similarly, citing Aries RFCs as good example also surprises me. These RFCs are too Indy-dependent that somebody outside that community can hardly understand them (let alone use them). I really hope that the CCG will not come up with something which is HTTP-only (or browser-only), but IMHO following the path of Hyperledger Indy/Aries is the wrong way.

 

Of course this is always my subjective opinion.

 

Best,

Nikos

 

  

 

From: Daniel Hardman <daniel.hardman@evernym.com> 
Sent: Friday, April 10, 2020 6:42 PM
To: Orie Steele <orie@transmute.industries>
Cc: Manu Sporny <msporny@digitalbazaar.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>
Subject: Re: Different Verifiable Credential protocols? (was: Re: Please vote to approve/disapprove the new charter)

 

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 < <mailto:orie@transmute.industries> 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/> 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> 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/> 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 < <mailto:msporny@digitalbazaar.com> 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> https://github.com/schmich/instascan

and Web Bluetooth is released in many of the latest/popular browsers:

 <https://caniuse.com/#feat=web-bluetooth> https://caniuse.com/#feat=web-bluetooth

... and WebNFC just went into Origin trials in Chrome:

 <https://developers.chrome.com/origintrials/#/view_trial/236438980436951041> 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> 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/> https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
 <https://tinyurl.com/veres-one-launches> https://tinyurl.com/veres-one-launches




 

-- 

ORIE STEELE

Chief Technical Officer

 <http://www.transmute.industries> www.transmute.industries

 

 <https://www.transmute.industries/>