Re: Oracles as Issuers

Sam's use-case does seem to be applicable to my points about Oracles as
Issuers. As I interpret the diagrams, with or without Orgbook, the data
subject is not a holder and there's no value for introducing a holder
function associated with any DID.

The presumption that a wallet / agent is always both a PDP and a store of
VCs does not recognize a vast number of VC use-cases, What is the best way
to encourage adoption of VCs in a privacy-controlled way, regardless of
whether there's a holder in the middle?

Thanks,
Adrian


On Tue, Aug 18, 2020 at 7:14 PM Wayne Chang <wyc@fastmail.fm> wrote:

> Hey Adrian,
>
> I believe this early work item may be relevant to some of your points, and
> extensible to cover more:
>
> https://w3c-ccg.github.io/vc-http-api/
> https://github.com/w3c-ccg/vc-http-api
>
> There could be room to grow it to add interfaces for notifications,
> parameters used for PEPs + PDPs, and connections to parties as necessary. I
> also agree that the ongoing work on GNAP is very relevant to the clean
> separation between PDPs and PEPs as you describe.
>
> Best,
> - Wayne
>
> On Thu, Aug 13, 2020, at 11:36 PM, Adrian Gropper wrote:
>
> Please help me draft a PR to the appropriate place [did-core?
> did-use-cases? secure-data-store?] that describes the API for issuing a
> verifiable credential such that:
>
> The Issuer:
> - *MAY* or *SHOULD* emit a VC via a standard API (e.g. a secure data
> store)
> - the API protocol *MUST* support connection to both Holders or Verifiers
> [DIDcomm and/or HTTPS, etc...]
> - the API *MUST* be a policy enforcement point (PEP). (the issuer can run
> their own PDP, if they choose)
> - the authority respected by the PEP *MUST* be either the Issuer or the
> Data Subject
> - the authority is a policy decision point (PDP) operated on behalf of
> *either* the Issuer or the Data Subject
> - a requesting party *MUST* present their request to the PDP (not the PEP)
> - that supports both self-authorized and subject-authorized requests
> *MUST* offer separate APIs to reflect the separate PDPs.
> - *SHOULD* notify the data subject when they receive or process an access
> request via the self-authorized API
>
> The main goal here is to encourage Issuers to behave as oracles and remove
> the adoption barrier of having to have a Holder when all the data subject
> needs is an authorization server because they don't care if the Issuer
> knows about the Verifier.
>
> Another goal is to simplify revocation in cases where the data subject
> doesn't care if the Issuer knows about the Verifier.
>
> Yet another goal is to protect the privacy of data subjects who would
> prefer to process Verifier (as requesting party) access requests (scope,
> purpose, credential) at a policy decision point (PDP) separate from the
> Issuer (as PEP). The Verifier would then be given a capability to be
> presented to the Issuer PEP.
>
> We recognize that the requesting party (Verifier) has legitimate privacy
> concerns of their own and may prefer to present their credentials to the
> Issuer rather than the Holder. In these cases, the Issuer MAY offer a PDP
> of their own and the data subject SHOULD be notified of the scope, purpose,
> and identity of the requesting party (Verifier) as allowed by the policies
> of the PDP.
>
> - Adrian
>
>
>
> On Wed, Aug 12, 2020 at 12:16 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> On Wed, 12 Aug 2020 at 00:35, Adrian Gropper <agropper@healthurl.com>
> wrote:
>
> During today's CCG call we discussed ways that an institution would make
> public assertions about their practices. The assertions could be:
> - policies, commitments, or audits that are associated with the
> institution in general, or
> - certifications, badges, or licenses associated with specific individuals.
>
> Either way, the assertions are typically public such as state medical
> licenses, federal DEA numbers, voter rolls, real estate, food and liquor
> licenses, law enforcement, license plates, D&B reports, court filings, sex
> offenders, white and yellow pages, etc. Access to these assertions was
> seldom limited before networking because there was sufficient friction to
> keep all but the most dedicated data brokers at bay. The friction also
> drove a business model around sale of this public information.
>
> These public assertions are now the feedstock for thousands of data
> brokers operating as a broad surveillance mechanism, privatized, and
> without much transparency or regulation.
>
> I call these public assertion issuers oracles because it matches how the
> term is used in smart contracts.
>
> An oracle's public assertions can be open, behind a paywall, or restricted
> access. In the case of pay or access restrictions, the reason typically has
> nothing to do with the consent of the data subject. The restriction is
> based on the credentials of the requesting party such as law enforcement
> access to auto registry information or a no-fly list. Data brokers consume
> assertions from other oracles and act as oracles themselves, typically
> without the consent of the data subject.
>
> Because consent does not figure into the practices of most oracles, be
> they public or private, the only reason to introduce a holder and their
> wallet is to avoid loss of privacy through traffic analysis. That's an
> important feature but there are many situations where the data subject
> really has no worries about the oracle knowing who the verifiers are.
> Oracles can, by policy, choose to erase access logs after 24 hours. The
> assertions are often subject to revocation and having the verifier contact
> the oracle directly is more efficient than dead-drops.
>
> In most any case, the data subject can always choose to make a copy of the
> assertion by the oracle in the form of a verifiable credential.
>
> My point is that oracles could be using VCs regardless of what assertions
> they're making or whether the VC is going to a holder or a verifier. The
> only difference is whether the request is made by the data subject
> themselves (to go to their wallet) or by a verifier directly. Payment and
> revocation would need to be considered, of course. Some oracles would need
> to process requests as discussed in
> https://lists.w3.org/Archives/Public/public-credentials/2020May/0049.html
> using protocols like GNAP
> https://tools.ietf.org/html/draft-richer-transactional-authz-09.
>
> Oracles as Issuers has protocol implications for both access control and
> transport. How should we continue this discussion?
>
>
> Very much agree that verifiable claims can be used as oracles
>
> That's how you tie together block chain crypto and the web, in order to
> make things scale to millions of participants
>
>
>
> - Adrian
>
>
>