RE: Oracles as Issuers

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 <mailto:D.W.Chadwick@kent.ac.uk> > wrote:
> 




  <https://docs.google.com/uc?export=download&id=1d4IPCRrht6DZ7xq3ORNz4dSQlzbAyCuv&revid=0B_c5ph_NlSsoNnpiSHdQY2Q2YmZ1RzRObDFjYlN1MmVIUnNFPQ> 

 

On Fri, Aug 14, 2020 at 6:35 AM David Chadwick <D.W.Chadwick@kent.ac.uk <mailto: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>  <mailto: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> >
>     <mailto: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> >
>     <mailto: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
>
>     >
>
>
>