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: Wed, 21 Jul 2021 12:58:35 -0400
Message-ID: <CANYRo8hQConk1s2RoczJV20_m1hBbh6mh+fcyRVGxtT-_X0S9A@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C Credentials Community Group <public-credentials@w3.org>
Sure! It's in Topic 6: Limitations and Safeguards on Sharing

   -


"ONC should clarify that API providers are not obligated to protect
> patients by identifying "suspicious" apps. API providers may suspend API
> access to an app that has breached the API provider's terms of service13,
> or appears to have been compromised, or if the app poses a threat to the
> provider's own system. However, patients must be able to override this
> suspension (except in the case where an app poses threat to the provider's
> own system or violates allowable terms of service)."

DoS attacks are not mentioned by name but they were the example discussed
during the hearings. The logic was to warn the patient that their right of
access (and their ability to delegate access) was in jeopardy. This is
because the patient has a right to control and delegate access to an
end-user but, in most cases, the patient has no control over the client
(app) that will be the agent of the end-user (often a doctor).

I hope this is clear from a patient rights / human rights perspective, but
there's more for us to think about from the technical perspective
in VC-HTTP API.

As best I can tell, the ability of the VC Subject (the RO) to control
access to the VC resource server (RS) can be either through capabilities or
registration (of a key that will sign an access token). If an end-user's
client presents a capability and that capability violates the Terms of Use
of the RS, then the RS has to warn the Subject (as RO) or just revoke that
particular capability unilaterally. This unilateral right for the RS as VC
Issuer to protect itself and its other customers is the "Adrian Clause" in
the UMA 2 spec.

Can anyone confirm that the Issuer will need to either register a signing
key (by value or reference) for each RO or they will need to store an
identifier for whatever capabilities they issue to an RO in order for them
to effectively exercise their Adrian Clause rights in case the RO or their
delegate violates the Issuer's Terms of Use.

- Adrian



On Wed, Jul 21, 2021 at 8:40 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 7/20/21 4:09 PM, Adrian Gropper wrote:
> > I have a lot of experience with the point Manu is making.
>
> Great, then please answer the question I asked.
>
> I read the document you linked to, it's 30 pages... I have no idea which
> point
> in that document you are attempting to make and it's dangerous to guess.
> I'd
> like you to spell it out for the group.
>
> After you do that, I'm getting clarity on what I think you are concerned
> about
> (but I've thought that many times before in this conversation, so who
> knows!?) :).
>
> -- 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 Wednesday, 21 July 2021 16:59:00 UTC

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