- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Fri, 3 Jan 2020 14:11:36 +0000
- To: public-credentials@w3.org
Absolutely correct. In fact the way the holder/subject registers with the Issuer is of critical importance, and is potentially the most important (and potentially vulnerable) link in the trust chain. On 03/01/2020 13:29, John, Anil wrote: > I is also important to note that "Before an Issuer decides to issue a credential to a Holder, the manner in which it may decide to first act as a Verifier in order to verify some credentials that the Holder presents to it" may not necessarily be using a DID/VC flow -- i.e. the Issuer may have existing validation and verification processes it may leverage to ensure that the Holder/Subject (am assuming that in this case they are the same) is indeed the proper beneficiary of the benefits/entitlements that the Issuer is authoritative for. > > Best Regards, > > Anil > > -----Original Message----- > From: David Chadwick <D.W.Chadwick@kent.ac.uk> > Sent: Friday, January 3, 2020 5:33 AM > To: public-credentials@w3.org > Subject: Re: the intersection between Swagger-style APIs and SSI/decentralized identity > > It is important to note that the terms Issuer, Holder and Verifier are ROLES, not entities. An entity can play any of the three roles at any time. > > So it is quite proper to say > > "Before an Issuer decides to issue a credential to a Holder, it may decide to first act as a Verifier in order to verify some credentials that the Holder presents to it. It may also act as a Holder to present some of the credential that it holds." > > Kind regards > David > > On 02/01/2020 18:22, Deventer, M.O. (Oskar) van wrote: >> 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.gm >>> a >>> il.com%3E&References=%3CCAFBYrUorm5UF8CjRqkFMJ4W3HuBAH-f5V95M6%3D8xbz >>> y >>> 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 Friday, 3 January 2020 14:11:47 UTC