Re: Oracles as Issuers

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