Re: Different Verifiable Credential protocols?

+1

On 11/04/2020 04:45, Nikos Fotiou wrote:
>
> 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 <orie@transmute.industries 
> <mailto: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 <mailto: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 <http://www.transmute.industries>
>
>     <https://www.transmute.industries/>
>

Received on Friday, 10 April 2020 17:36:50 UTC