Re: Oracles as Issuers

On 2020-08-12 5:04 am, Adrian Gropper wrote:
> 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.

I didn't know these acronyms; for others who might be following this 
thread, I believe:

PDP = Policy Decision Point

PEP = Policy Enforcement Point


Correct?


Steven



> 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