Re: Oracles as Issuers

I see identity in terms of policies and capabilities. The policies are
associated with PDPs where identity matters and storage is minimal. The
capabilities are associated with PEPs where resources are stored and the
only identity that matters is the resource customer or controller. The
resource server need not store policies to any significant extent. This is
the separation of concerns model that leads to decentralized AND generative
systems.

In these terms, both the oracle and the issuer are protected resources
(PEPs) with standard APIs for interoperability. For generativity, the same
API should be used  regardless of whether the connection is to a holder or
a verifier. Therefore the API would have a VC data model and capabilities
protection. The only policies at the resource are of the resource server
entity (oracle or issuer) and not of the data subject of the VC. The data
subject's policies are safe within a wallet or agent that acts as the PDP.

- Adrian


On Wed, Aug 12, 2020 at 7:42 AM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> Adrian, this is a very interesting topic. However, what I find most
> intriguing is your final sentence about how oracles have implications on
> transport and protocol. I would think that an oracle would behave exactly
> the same way any other issuer does as far as transport and protocol are
> concerned. So can you say a little bit more about what you have in mind
> when you say there are implications?
>
> On Tue, Aug 11, 2020, 4:34 PM 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?
>>
>> - Adrian
>>
>