W3C home > Mailing lists > Public > public-credentials@w3.org > July 2021

Re: Censoring as an Issuer (Re: VC HTTP API Telecon Minutes for 2021-07-13)

From: Adrian Gropper <agropper@healthurl.com>
Date: Tue, 20 Jul 2021 16:09:00 -0400
Message-ID: <CANYRo8iEZe0vjX2Fv75NnVBkankY3ghn1tvUGmsi0aXLYNYh2w@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials CG <public-credentials@w3.org>
I have a lot of experience with the point Manu is making. In UMA 2.0, they
actually named the point that the sovereign resource server always has the
last word "the Adrian Clause". (it's the only informally named clause in
UMA that I know of). I was also, along with Google and a few others, asked
to testify on this for the 2014 API Task Force
https://www.healthit.gov/sites/default/files/facas/SingleSourceofTruth-APITFRecommendations.pdf
.

I'm happy to provide details,

- Adrian

On Tue, Jul 20, 2021 at 1:58 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 7/20/21 12:14 PM, Adrian Gropper wrote:
> > The linkage of control to possession based on OAuth 2-style API client
> > credentials gives the sovereign Issuer the ability to censor or specify
> > the end-user's client.
>
> Replace "Oauth2" with /any authorization mechanism/ and you still have the
> same problem.
>
> The server can always deny requests, even legitimate ones. Full. Stop.
>
> An Internet-based server can always censor an Internet-based client. If
> this
> were not possible, every server on the Internet could be
> Denial-of-Service'd
> out of existence.
>
> I continue to be convinced that you don't understand what the Issuer
> endpoints
> of the VC HTTP API do:
>
> https://w3c-ccg.github.io/vc-http-api/issuer.html
>
> Either that, or I'm being fantastically dense (which I do admit is a
> possibility). Please help me understand... how is what I said above not
> true?
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>
Received on Tuesday, 20 July 2021 20:09:24 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:18 UTC