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

What you're asking isn't crazy or unreasonable. However, piecemeal
standards tasks like that tend to reinforce a bifurcation of the problem:
create a work item for the HTTP dimension, and another work item for some
other dimension (either as a separate artifact, or a delayed reconciliation
with the original artifact). Let the second item live or die according to
its independent momentum.

In some cases, this might be fine. For example, I had no objection to an
HTTP API for *internal* (Alice-to-Alice) issuer coordination. If I had
wanted to propose a non-HTTP alternative, I felt very free to do so; I
imagine my proposal would have received a professional and fair reception.
I only began to object when a scope change was proposed such that the work
item would be recast as also a standard for *external* (Alice-to-Bob)
interactions during issuance. Now if I wanted standardized issuance over
anything beyond HTTP, I would need to justify and manage it separately; use
cases I cared about would inevitably be marginalized. (I raised a similar
concern about the EDV effort when it was first described by Manu. Manu
clarified that his intent was to support multiple transports, and that HTTP
was just the easiest illustration. I took him at his word and went silent.)

Many of the items you list have not been brought to the CCG because they
seemed not to fit well with the interests or direction of the group. That's
just being practical, not a maverick -- and my question about charter scope
is me trying to evaluate whether I'm doing it wisely. Your CLSignature2019
examples are an interesting case in point. I suspect most people in the CCG
have no interest in them, so I haven't bothered y'all. If you want to know
more, see my postscript.

I guess my response could be summarized like this: although collaboration
is a good thing, I'm not convinced that the right way to do it is always to
open work items in this group. And I'm not convinced it's not, either. It's
just complicated. I hope that attitude doesn't feel crazy or unreasonable,
either.

--Daniel

PS.  Formal documentation on CL signature types has been available since at
least May 2016
<https://github.com/hyperledger-archives/indy-anoncreds/blob/master/docs/anoncred-usecase0.pdf>.
But just adding definitions of them to CCG docs would open up a rats nest
of assumptions that would bloat docs to unpack, and that wouldn't lead to
any meaningful interoperability without far deeper surgery. (Ask old timers
about the monster PR that Lovesh and I raised when we first tried to
explain ZKPs inside the VC spec draft.) We'd have to reframe expectations
about what's being signed, and when, and where and how it should be
evaluated. In Indy creds, the signature is proved but not revealed in a
presentation, so evaluating a CLSignature2019 value on an issued credential
doesn't give support for Indy creds in the way one might expect. Plus, the
keys that are used to sign aren't necessarily declared in the DID doc, so a
universal resolver can't be relied upon to give them to you. Plus,
signatures are field-level, not cred-level. Plus, in order to do ZKP
operations on a particular field, we need a second representation of the
data that is suitable to use as input to numeric and cryptographic
operations. Etc. All of this messiness is sidestepped by the VC Data Model
being deliberately non-specific, allowing very flexible conceptions of
proof that are not just signature values. The vague verbiage in the spec
was a calculated and negotiated choice, not anybody being lazy, failing to
document concepts, or being proprietary.


On Fri, Apr 10, 2020 at 12:53 PM Orie Steele <orie@transmute.industries>
wrote:

> I don't want the group to dismiss your concerns.
>
> I want you to open work items that address your concerns, and invite
> collaboration to address them in the W3C.
>
> I think the scope of the working group is such that all your concerns can
> be addressed, assuming there were work items created to address them.
>
> As a newer W3C member, it's possible I'm a bit biased by the wikipedia
> definition for world wide web.
>
> "The World Wide Web (WWW), commonly known as the Web, is an information
> system where documents and other web resources are identified by Uniform
> Resource Locators (URLs, such as https://www.example.com/), which may be
> interlinked by hypertext, and are accessible over the Internet. The
> resources of the WWW are transferred via the Hypertext Transfer Protocol
> (HTTP) and may be accessed by users by a software application called a web
> browser and are published by a software application called a web server."
>
> https://en.wikipedia.org/wiki/World_Wide_Web
>
> Integrating emerging technology with legacy systems is a core part of
> technology modernization, just because some people want to focus on that
> part, doesn't mean that those same people can't also work on wholesale
> replacing of legacy systems...
>
> For example, I personally work on did:elem a blockchain based DID Method,
> and also on did:web and did:key... Part of why I work on did:web is that
> some potential adopters of verifiable credentials want to use only existing
> (legacy) technologies for their identifier infrastructure, but they also
> want to use new emerging standards.
>
> There are pro's and con's for every technology, I work on many things
> which I think are not perfect, GPG is an example... I don't love key
> servers... but GPG is still used to sign git commit messages and software
> distributions... I feel similar about HTTP, it has issues... but it also
> has lots of users... who I want to support.
>
> I also want to support the things you care about, such as DIDComm, Aries,
> Indy, ZKPs, etc... Are there any work items in the W3C that you can point
> me to, today where I can learn more about these technologies and how they
> are interoperable / work with the scope defined in the current charter?
>
> For example, I think it would be really helpful to provide better
> definitions for:
>
> CLSignature2019, CLCredentialDefinition2019
> I'd be happy to help with that, or otherwise suring up the relationship
> between W3C Documentation, VC Data Model and CL Signatures.
>
> OS
>
>
>
>
> On Fri, Apr 10, 2020 at 12:33 PM Daniel Hardman <
> daniel.hardman@evernym.com> wrote:
>
>> @Orie:
>>
>> I am not "attacking HTTP and Web Technologies" or "objecting to HTTP and
>> Web Technologies," nor am I "frustrated that a large number of W3C members
>> love working on web technologies." Web technologies are great. I'm using
>> them right now as I process my email and browse away. (BTW, would you feel
>> welcomed by such language, if you felt it described your behavior unfairly?)
>>
>> In some cases I *am* "objecting to the standardization of Web and HTTP
>> APIs for the VC Data Model." My objection is to the assumption that we
>> should have one solution for HTTP, and a different and later solution for
>> everything else. My argument has been that bifurcating the problems this
>> way does not deliver solutions faster to enterprises, but it does
>> marginalize the developing world and enthrone strongly connected enterprise
>> servers in a power position (how many private individuals are going to run
>> a web server to host the standard verifier API we're working on?).
>>
>> It sounds like you want the group to dismiss my concern and buy into your
>> preferred assumption, and that you feel the need to "be blunt" that my
>> concern isn't resonating: "different communities have different
>> priorities... This is the W3C." That is the opposite answer to my question
>> from the one you and Manu implied when you said the scope was super
>> inclusive. And this is the very question I raised about the charter. If my
>> concern doesn't resonate, that's *totally fine* -- just tell me I'm
>> worried about something that's out of scope, and I'll go quiet. But don't
>> simultaneously claim the group wants to think about everything, and then
>> take me to task for insisting that we think broader than HTTP. It feels
>> unreasonable to try to have it both ways.
>>
>> @Nikos
>>
>> I agree that Indy is ZKP-centric, but please notice that I didn't bring
>> up Indy or the poison pill of ZKPs, anywhere in the thread. Bringing such
>> things into the discussion is a way to create a straw-man version of what
>> I'm saying, and then get everyone to dismiss it by association.
>>
>> I also didn't bring up Aries in general, but rather 2 specific RFCs.
>> Those RFCs are not Indy-dependent, and they say so. They describe a
>> workflow that works over HTTP as well as bluetooth, email, and sneakernet.
>> And they describe credential usage patterns that apply to any VC type at
>> all. If you've studied them and had a frustrating experience, I apologize.
>> That would be a fair reason not to like them, but not a fair reason to
>> ignore them if Orie's broader scope is really the intent of the group.
>>
>> On Fri, Apr 10, 2020 at 10:47 AM Orie Steele <orie@transmute.industries>
>> wrote:
>>
>>> 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>
>>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>