Re: Oracles as Issuers

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
>