Re: Oracles as Issuers

Hi David,

Apologies for the delay.

I appreciate your review, but I think we're still talking past each other.
Part of the problem is that you may be equating Data Subject with Holder
and I'm not. In my world, the Data Subject's sovereignty derives from
operating an agent as a PDP, regardless of where VCs are held under
corresponding PEP control. Some Data Subjects may choose to also operate a
secure storage for VCs and other documents, but that is optional and
incidental, *and none of the Issuer's business*.

Stated another way, the Issuer only deals with one identity and many
capabilities. The one identity is the Data Subject. The various
capabilities are all derived from the authority of the Data Subject as
specified when the Data Subject (identity) registered their agent as the
PDP for the issuer's VC API.

More inline...

On Fri, Aug 14, 2020 at 9:33 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
wrote:

>
> On 14/08/2020 08:49, Adrian Gropper wrote:
> > Hi David,
> >
> > I think my proposal enhances privacy in every way.
> Sorry but you have not convinced me of this!
> > The Issuer does not have any choice in whether the data subject’s
> > agent is also a store for VCs. All I’m doing is promoting the use of
> > VCs. I am also promoting the use of secure data stores because Issuers
> > will be able to use SDS in many more cases.
>
> I think you are envisaging the SDS as part of the holder's agent
> (conceptually). Whilst it is true that the holder's agent talks to both
> Issuers and Verifiers in the VC model, nevertheless they are separate
> access points and are different, and would not be used "the other way
> around".  So perhaps if you re-phrased your text to indicate that two
> separate and distinct access points exist, one for issuers and one for
> verifiers, that would be more convincing.
>

I'm not. I'm envisaging the SDS as a vendor to the issuer, not the holder.
The SDS is a storage utility. It should be designed to serve Issuers and
Holders and Verifiers without distinction.

I don't see the SDS as an agent of any of them. Agent implies some control,
possibly in a fiduciary relationship. Storage, especially if encrypted, is
merely a processing function for hire and has little or no ability to act
as an agent except in the most trivial way, by securely evaluating a
capability. In my separation of concerns vision, SDS is always a PEP and
never a PDP.

Back to my core point, that Issuers should be issuing a VC without
considering where it's going to:
- The Issuer operates an API as a PEP (or maybe delegates that role to an
SDS they hire).
- The Data Subject operates an agent as a PDP, and specifies to the Issuer
that it is the authority for release of VCs to anywhere.
- This PDP is, as you say above, the Data Subject's agent.
- As the agent, the PDP evaluates requests from would-be Verifiers and
issues them EITHER a capability or the VC itself.

This is a key reason why I claim privacy is enhanced. The data holder gets
to decide how to process access requests. The data holder gets to choose
whether to respond with a VC or with a capability to get a VC. The data
holder gets to decide whether to use a SDS of their own or use an SDS
operated by the Issuer. The data holder can exercise this choice separately
for each Issuer they deal with depending on whether they are concerned if
the Issuer knows of the Verifier or if they're concerned that the Verifier
is unwilling to deal with intermediary holders.

Let's take an education example. A Verifier might want both grade report
and a recommendation VCs. The grade report VC can be plain text in a data
subject's holder. Because the data subject should not see it, the
recommendation VC has to either come directly from the Issuer or it has to
be encrypted with the Verifier's key so it can be held by the subject
without seeing it. In that case, the Issuer must either get the Verifier's
public or symmetric key somehow.

It may be a while before verifiers are willing to deal with encryption and
revocation lists. Giving a Verifier a capability to deal with an Issuer's
VC API directly could be a significant driver of adoption. In the early
days, the Verifier posts a public VC endpoint, as a data subject, I send a
capability to that VC endpoint along with a pointer to some PEP. The
Verifier, gets a VC from some SDS.

That leaves the case of the recommendation VC. When the Issuer PEP is
presented with a capability to release a letter of recommendation, it needs
to have the encryption key of the Verifier. I'm not sure how this is best
handled in terms of capabilities because it is an identity issue. In this
case, the Issuer does have to operate a PDP of their own. In other words,
recommendation VCs are behind a different Issuer API than grade report VCs.
The recommendation API could be protected by just plain old OAuth2.

[the rest is snipped until we settle this]

- Adrian