- From: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl>
- Date: Thu, 2 Jan 2020 18:22:04 +0000
- To: Steven Rowat <steven_rowat@sunshine.net>
- CC: W3C-CCG <public-credentials@w3.org>
Hi Steven, > > As you see, I am using the terms issue, hold and verify only as nouns. > Did you mean 'verbs' rather than 'nouns'? Oops, of course. I am urging all to be careful with terminology, and then I make such a sloppy error ;-) I meant to say the following: Here is an example of a sentence in this style: "Before a Party decides to issue a credential to another Party, or to present a credential that it holds, it may decide to verify some credentials of that other Party first." As you see, I am using the terms issue, hold and verify only as verbs. (Hence avoiding the nouns Issuers, Holder and Verifier.) Oskar -----Original Message----- From: Steven Rowat <steven_rowat@sunshine.net> Sent: 02 January 2020 17:47 To: Deventer, M.O. (Oskar) van <oskar.vandeventer@tno.nl> Cc: W3C-CCG <public-credentials@w3.org> Subject: Re: the intersection between Swagger-style APIs and SSI/decentralized identity On 2020-01-02 12:31 am, Deventer, M.O. (Oskar) van wrote: > Hi Daniel, > > Thank you. > > Please note that we need to be more careful with our terminology. A > "Holder" does not verify an "Issuer" or "Verifier". I suggest that, > where usefull, we use the generic term "Party" that can switch between > these roles. > > Here is an example of a sentence in this style: > "Before a Party decides to issue a credential to another Party, or to > present a credential that it holds, it may decide to verify some > credentials of that other Party first." > > As you see, I am using the terms issue, hold and verify only as nouns. Did you mean 'verbs' rather than 'nouns'? Steven Rowat > > > Oskar > > > -------- Original message -------- > From: Daniel Hardman <daniel.hardman@evernym.com> > Date: 31/12/2019 20:42 (GMT+01:00) > To: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@tno.nl> > Cc: W3C-CCG <public-credentials@w3.org> > Subject: Re: the intersection between Swagger-style APIs and > SSI/decentralized identity > > Oskar: thank you for that diagram. Very insightful. I agree that the > party that's acting as an issuer or verifier needs to be able to > organically switch roles. In the middle of issuing, the potential > holder needs to be able to challenge the potential issuer to prove its > bona fides; in the middle of proving, the holder needs to be able to > challenge the verifier to prove its bona fides. Your diagram is spot > on. This is an excellent example of why APIs that contemplate a single > workflow where initiation only happens on one side, and all flows are > hosted on one side, are too simplistic. > > (This composability phenomenon is why the Aries community has begun > talking about subprotocol and coprotocols > <https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols#composable>. > I think the ideas there are very early and would profit from > additional use cases like Oskar's.) > > On Tue, Dec 31, 2019 at 11:24 AM Deventer, M.O. (Oskar) van > <oskar.vandeventer@tno.nl <mailto:oskar.vandeventer@tno.nl>> wrote: > > Hi Daniel,____ > > __ __ > > Your analysis makes a lot of sense to me, and deserves discussion > at more length. ____ > > __ __ > > At TNO, we have noted an asymmetry in most of the SSI use cases > presented in papers and at conferences, where the Issuer and > Verifier roles are typically big organisations with servers, > whereas the Holder role is typically an individual (citizens, > consumer, patient, employee, student). This asymmetry is one of > the major reasons of much online fraud today. The individual > simply does not have the means to say “hey website, proof to me > that you indeed do have a Dutch bank license” (individual in the > Verifier role), or “that one is a good seller” (individual in the > Issuer role, web-of-trust case). So it will be good to work on > technical solutions, where symmetry and PKI-lessness is achieved > at least at the protocol level. But it may be equally useful to > work out more use cases where an individual is in the Verifier or > Issuer role in interactions with a big organisations or another > individual.____ > > __ __ > > The figure below illustrates a use case that shows symmetry > between Consumer “C” and a Travel site “T”. Both parties > intermittently act as Issuer, Holder and Verifier in a single > transaction exchange. We should have more of such use cases, in > order to create the so-needed awareness and sense of urgency with > W3C-CCG and elsewhere.____ > > __ __ > > ____ > > One of the targets of the European H2020 NGI eSSIF-Lab project (of > which I am the scientific coordinator) is the creation/integration > of open-source wallet software that supports this symmetry and > that has the required Issuer and Verifier functionalities. We are > planning to offer a bounty of up to 50 kEUR to (European) parties > that will build such functionality. Symmetry and PKI-less > operation of the transport protocols (plural, including Bluetooth, > …) may be an important element in this.____ > > __ __ > > Oskar____ > > __ __ > > __ __ > > From: Daniel Hardman <daniel.hardman@evernym.com > <mailto:daniel.hardman@evernym.com?Subject=Re%3A%20the%20intersection%20between%20Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply-To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gmail.com%3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gmail.com%3E>> > Date: Mon, 30 Dec 2019 12:54:38 -0700 > Message-ID: > > <CAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6=8xbzyDPg-YNg@mail.gmail.com > <mailto:8xbzyDPg-YNg@mail.gmail.com>> > > Cc: W3C Credentials CG <public-credentials@w3.org > <mailto:public-credentials@w3.org?Subject=Re%3A%20the%20intersection%20between%20Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply-To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gmail.com%3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gmail.com%3E>>, > Markus Sabadello <markus@danubetech.com > <mailto:markus@danubetech.com?Subject=Re%3A%20the%20intersection%20between%20Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply-To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gmail.com%3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gmail.com%3E>>, > Justin P Richer <jricher@mit.edu > > <mailto:jricher@mit.edu?Subject=Re%3A%20the%20intersection%20between%2 > 0Swagger-style%20APIs%20and%20SSI%2Fdecentralized%20identity&In-Reply- > To=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzyDPg-YNg%40mail.gma > il.com%3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbzy > DPg-YNg%40mail.gmail.com%3E>>____ > > __ __ > > Markus has recently proposed a work item for the CCG to develop > Swagger-style APIs for issuers and verifiers. Justin has recently > proposed a charter for a TxAuth group to start working on > HTTP-based APIs to accomplish delegation. Digital Bazaar has > advocated their RESTful Credential Handler API (CHAPI) in CCG and > other circles as well. No doubt many others on this thread are > aware of efforts to standardize APIs with similar style and > similar intersection to the SSI/decentralized identity space.____ > > __ __ > > I would like to raise a red flag about such efforts, and trigger a > thoughtful follow-up conversation. I love Swagger-style APIs and > have advocated them extensively at past junctures of my career, > but I am concerned that they are exactly the wrong thing to > standardize right now. I'll explain my concerns below, in red, and > then offer an alternative path that has most of the same benefits, > in blue.____ > > __ __ > > 1. RESTful APIs are web-only.____ > > __ __ > > How do two farmers with cheap android devices in the highlands of > Bolivia (or a Canadian Mounty and a speeder on a lonely highway in > Yukon Territory, or friends in Frankfurt whose cell service has a > brownlout, or two anti-government protesters) use RESTful APIs to > transact business? If the answer is, "they subscribe to a service > in the cloud so they can talk device-to-device," I hope we are > embarrassed. We need something that also works over BlueTooth and > email and other transports where a web server isn't a > component.____ > > __ __ > > By standardizing a solution that doesn't think about these > scenarios, we are further marginalizing them, and we are > enthroning a > /you-must-be-connected-and-you-can-be-surveilled/ model that > guarantees /it-isnt-a-standard/ FUD for any other efforts to fix > the problem.____ > > __ __ > > 2. RESTful APIs perpetuate the PKI model that we claim to be > replacing with DIDs.____ > > __ __ > > Servers are authenticated in these APIs with a cert. Clients are > authenticated with a session that follows from an OAuth token or > an API key or basic auth material. It is possible to imagine "DID > Auth" being used for a client of a RESTful API, and there have > been several efforts to describe and standardize such a thing. So > far, none has meaningful traction, so all APIs in the SSI space > that use APIs are also allowing non-DID authentication for > clients. But even if we solve the problem for the client side, > nobody is proposing to solve the problem for the server side. > Institutions in these APIs don't use DIDs for anything meaningful. > Thus none of the decentralized properties of DIDs are brought to > bear for the server side of the interaction, and any decentralized > qualities of DIDs are relegated to minor, optional status for > clients.____ > > > 3. RESTful APIs foster a power imbalance____ > > __ __ > > What if there's a standard way for institutions to be a verifier > or issuer, but no way for ordinary people to be a verifier or > issuer? Or a standard way for institutions to delegate, but no way > for ordinary people to do it? That's effectively what APIs like > the ones I mentioned above guarantee. There are multiple reasons > why, including:____ > > __·__Institutions have web servers; farmers in Bolivia don't. > (Saying that they *could* is not helpful; we're just creating more > adoption burden for SSI by making the tech harder and more > expensive for them.)____ > > __·__Servers can't make the first move in RESTful APIs; everything > begins when a client initiates the interaction. This makes it > natural for an institution (or a regulatory regime) to impose > terms of service or reputation criteria on a client, and unnatural > for a client to do the opposite. It's also convenient for hackers > and surveillers, since they know they can catch all interactions > at inception by simply listening on the server.____ > > __·__Because these APIs are online-only, and because the server > always waits for the client to make the first move, they can only > be operated by those who have a 24x7x365 cloud presence. > Institutions and ordinary people don't have equal access to > 24x7x365 cloud capabilities.____ > > __·__Because these APIs are secured on the server side by a cert, > they can only be operated by those who have access to expensive, > premium, centralized reputation. Again, institutions and people > don't have equal access to this.____ > > This is not an exhaustive list of my concerns, but I think it's > enough to trigger a conversation. > > Proposed Alternative____ > > __ __ > > We create web APIs, but we think about them differently. We > conceive of all of them as exchanges of messages that could also > be accomplished over BlueTooth, email, etc. HTTP(S) is just > another transport, where messages happen to be passed by HTTP POST > (or GET, as appropriate). Security properties associated with the > exchange are based on the control of DIDs and embodied in the > messages themselves (e.g., through encryption/signing), not in a > transport layer. All semantics for the interaction are conveyed by > the message content. The traditional URL namespacing of Swagger > can still exist, but it becomes less interesting, since the > message content must be enough to convey semantics on its own (so > the messages are enough in other transports). Either party can > initiate an interaction. Institutions and people are actually > peers.____ > > __ __ > > This is the world of didcomm and application-level protocols built > atop it; it's described in Aries RFC 0003 > <https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md>. > But before folks get their hackles up about not wanting to work > with Aries or DIF, note that I didn't propose that Aries protocols > have to be the basis for this approach. Instead, I proposed some > characteristics we need to avoid. Can we explore that assertion on > its merits, without getting immediately entangled in politics?____ > > __ __ > > There are already maybe 8-10 software stacks, some independent > from top to bottom, that implement an "API" for issuing > credentials and an "API" for verifying presentations based on the > model I just articulated. These implementations are demonstrably > interoperable with one another. By proposing a new work item for a > Swagger API for issuance and verification, we are walking away > from interoperability with these implementations, and we are > incurring all of the architectural disadvantages I highlighted in > red above.____ > > __ __ > > What if we did this instead?____ > > __·__Agree that for issuance and verification, the goal about > payloads and sequencing for HTTP calls should be alignment between > those defined in the Aries protocol and those used by people who > aren't Aries-centric. This could involve give and take in either > direction; I'm not proposing that it has to be done by simply > adopting the Aries work.____ > > __·__Agree not to depend on HTTP-specific constructs (e.g., HTTP > headers, HTTP status codes) to signal important semantics--so the > payloads could be exchanged over BlueTooth or email just as > easily.____ > > __·__Agree that, while URL namespacing gives us a nice hook into > Swagger-oriented tools, all semantics required for the interaction > are detectable from the payloads themselves.____ > > Then we'd have an HTTP solution that is Swagger-compatible but not > limited to HTTP. The "API" we created would be interoperable on a > much broader canvas than simple web.____ > > __ __ > > If we further agreed to this:____ > > __·__Authentication of both parties in the interaction will be > done on the basis of DID control, not on the basis of certs.____ > > Then we'd also eliminate the dependence on the web's flawed PKI > model, and the power imbalance of today's web. But I know this is > more controversial.____ > > _._,_._,_____ > > __ __ > > __ __ > > This message may contain information that is not intended for you. > If you are not the addressee or if this message was sent to you by > mistake, you are requested to inform the sender and delete the > message. TNO accepts no liability for the content of this e-mail, > for the manner in which you use it and for damage of any kind > resulting from the risks inherent to the electronic transmission > of messages. >
Received on Thursday, 2 January 2020 18:22:10 UTC