Re: Oracles as Issuers

Our pre-pandemic roadmap had us in this user flow.

[image: Screen Shot 2020-08-17 at 10.45.23 PM.png]
But with our new germ safe program, we want to attach information about
an organization's location to that Organization without solving the
keyholder administrator issue of the Orgbook. I want a trusted set of
public records such as a land & title registry or a fire marshal's Fire
Safety Plan database to establish a relationship with the Orgbook like I
pictured above.
What would be the best way to describe a system that connects public
relationships to the organization?




On Mon, Aug 17, 2020 at 4:52 PM <steve.e.magennis@gmail.com> wrote:

> Sam, in this scenario who do you, as the operator of the safety training
> system formally represent? Do you represent yourself as an independent 3rd
> party service, would you be acting as a formal representative of property
> management, the fire marshal, etc?
>
>
>
> -S
>
>
>
> *From:* Sam Mathews Chase <samantha@venn.agency>
> *Sent:* Monday, August 17, 2020 4:24 PM
> *To:* David Chadwick <D.W.Chadwick@kent.ac.uk>
> *Cc:* Adrian Gropper <agropper@healthurl.com>; W3C Credentials CG <
> public-credentials@w3.org>
> *Subject:* Re: Oracles as Issuers
>
>
>
> Can I add some context about the original conversation? I'm a little lost.
>
> I am making a credential that is issued from my safety training system on
> behalf of an organization's location signed by a fire marshall and
> published on the Orgbook.
> In this case, all parties would like to know who is verifying the veracity
> of my claims of safety training happening at specific locations. The public
> expects the fire marshal to do their role which is to inspect and sign off
> on the training and safety measures in place by the organization liable for
> properties in their region.
>
> Fire safety zones are owner managed information that must be made
> accessible to occupants. Fire  This is information that people are required
> to know but is notoriously difficult to disseminate. i.e. people don't read
> evacuation maps, training is imperfect.
>
> Why does there have to be an administrator/key holder for the
> organization?
>
>
>
> This, in my imagination, is a public wallet for a location or object that
> the public is collectively responsible for (be informed, act accordingly,
> participate) but an organization is ultimately liable for (pays property &
> casualty insurance). If any part of a managed and liable property is
> accessible to the public then the public safety information should be
> available and maintained by that organization in a public way.
>
>
>
> This is the use case I aim to achieve and so can we circle back to that or
> use my examples in your frameworks? I appreciate the discussion!
>
>
>
>
>
>
>
>
>
> >> On Aug 14, 2020, at 6:35 AM, David Chadwick <D.W.Chadwick@kent.ac.uk>
> wrote:
> > 
>
>
>
>
> On Fri, Aug 14, 2020 at 6:35 AM David Chadwick <D.W.Chadwick@kent.ac.uk>
> wrote:
>
>
> On 14/08/2020 08:49, Adrian Gropper wrote:
> > Hi David,
> >
> > I think my proposal enhances privacy in every way.
> Sorry but you have not convinced me of this!
> > The Issuer does not have any choice in whether the data subject’s
> > agent is also a store for VCs. All I’m doing is promoting the use of
> > VCs. I am also promoting the use of secure data stores because Issuers
> > will be able to use SDS in many more cases.
>
> I think you are envisaging the SDS as part of the holder's agent
> (conceptually). Whilst it is true that the holder's agent talks to both
> Issuers and Verifiers in the VC model, nevertheless they are separate
> access points and are different, and would not be used "the other way
> around".  So perhaps if you re-phrased your text to indicate that two
> separate and distinct access points exist, one for issuers and one for
> verifiers, that would be more convincing.
>
> >
> > As far as how I’m using PDP / PEP, it is very important that the
> > requesting parties go to the data subject‘s agent (the PDP) first
>
> the data subject's agent should be a PEP front end to a PDP. If you want
> you can require the PEP to accept access decision requests from the
> public. I think this would provide the functionality you need, and would
> conform to the standard model of a policy enforcement point.
>
>
> > so that the Issuer is not aware of their purpose or credentials or
> > even the requested scope. All the Issuer gets to know, IF the data
> > subject chooses to bypass their role as relay, is the Verifier's
> > endpoint and the scope granted via the capability.
> >
> > As far as revocation, the choice of revocation method is worth further
> > discussion. If we want to restrict issuers to ALWAYS use a dead-drop
> > or equivalent means for revocation in order to ensure that the VCs
> > they issue are the same no matter the choice of the data subject to
> > bypass their relay role, that is a separate matter to discuss. My main
> > point is to promote the use of VCs and reduce the cost of the agent of
> > the data subject by having it store only policies rather than both
> > policies and VCs.
>
> conceptually policies are stored in PAPs, evaluated by PDPs and enforced
> by PEPs. These can of course be combined in one software program, but
> conceptually they still exist in that program.
>
> Kind regards
>
> David
>
> >
> > - Adrian
> >
> > On Fri, Aug 14, 2020 at 2:50 AM David Chadwick
> > <D.W.Chadwick@kent.ac.uk <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
> >
> >     Hi Adrian
> >
> >
> >
> >     whilst your goals have some merit, your proposed way of achieving
> >     it has
> >
> >     some serious flaws, see below
> >
> >
> >
> >     On 14/08/2020 04:36, 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
> >
> >
> >
> >     connection to a verifier is in direct contradiction to the VC data
> >     model
> >
> >     and should be strongly opposed. One of the privacy strengths of
> >     VCs is
> >
> >     that the issuer does not know who the verifier is.
> >
> >
> >
> >     You say you want to cater for holders/subjects who do not care about
> >
> >     privacy, but by mandating this connection you are violating the
> >     rights
> >
> >     of subjects who do care about their privacy, because they wont be
> >     able
> >
> >     to protect it with what you propose.
> >
> >
> >
> >     > [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 is in direct contradiction to the standard PEP/PDP model.
> >
> >     Requesters contact PEPs, and PEPs contact their own PDPs. What you
> >     want
> >
> >     to achieve can still be achieved by defining a PEP with the
> >     properties
> >
> >     you require and not by changing the overall standard model.
> >
> >
> >
> >
> >
> >     > - 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.
> >
> >
> >
> >     You cant have users who do care about privacy and users who don't
> >     care
> >
> >     about privacy sharing the same revocation service, since the
> >     wishes of
> >
> >     the users who do care will be disregarded.
> >
> >
> >
> >     Kind regards
> >
> >
> >
> >     David
> >
> >
> >
> >     >
> >
> >     > 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 <mailto:melvincarvalho@gmail.com>
> >     <mailto:melvincarvalho@gmail.com
> >     <mailto:melvincarvalho@gmail.com>>> wrote:
> >
> >     >
> >
> >     >
> >
> >     >
> >
> >     >     On Wed, 12 Aug 2020 at 00:35, Adrian Gropper
> >
> >     >     <agropper@healthurl.com <mailto:agropper@healthurl.com>
> >     <mailto:agropper@healthurl.com <mailto: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
> >
> >     >
> >
> >
> >
>
>