Oracles as Issuers

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