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> 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
> <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>
> Cc: W3C Credentials CG <public-credentials@w3.org
> <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
> <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
> <jricher@mit.edu?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 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.
>
>