W3C home > Mailing lists > Public > public-credentials@w3.org > August 2021

Re: WoN Re: Public consultation on EU digital principles

From: Henry Story <henry.story@gmail.com>
Date: Tue, 10 Aug 2021 12:07:13 +0200
Cc: David Chadwick <d.w.chadwick@verifiablecredentials.info>, Bob Wyman <bob@wyman.us>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Message-Id: <F16CA1CE-15C6-4CB0-A711-52E73391351F@gmail.com>
To: daniel.hardman@gmail.com


> On 10. Aug 2021, at 10:50, Daniel Hardman <daniel.hardman@gmail.com> wrote:
> 
> I feel like decentralization is running into a difficult tension here: we want to democratize issuance (anyone can do it), but we want to trust a limited set of issuers (or at least, a limited set on any given topic). Anybody can create a COVID test result credential, but we only want to accept them if they were issued by a lab that we have reason to trust. Etc...

A good tension I think, one has to be a little careful that is all.
So democratize issuance does not mean that everyone has the same authority on every subject. 
But it does mean that everyone can speak. 

I think we have that here: everyone can issue a credential. 
But which issuers are going to be trusted on a topic is going to be a very 
different thing. 

Most people can be trusted to make the claim about which key they control.
And indeed we don’t completely trust them on that: we ask them to prove it
by using their private key.

In my linked data foaf network I can make claims about who my friends are,
and that can be verified by looking at which links point back, or just trusting me.
The problem is someone could buy a lot of domain names and create fake sock puppet 
WebIDs, with fake data associated with it, and people have been doing that 
massively on the social networks as part of disinformation campaigns.

So close personal social networks only works on a limited scale where
people know each other more or less personally. For close social networks
people can keep track of who they know, can call people up, go to their
parties, have teleconfs, and have all kinds of ways to help each other.


> One solution to this problem is registries: list trusted sources and have your software check whether the issuer is on approved/accredited list by querying. Of course this re-centralizes around the oracle.

Well not quite: in our social network case you keep a list of your friends and
you are the oracle for that. That is not centralisation. You are making a speech
act doing that, which entails some responsibility. 

When we are dealing with verifications of capabilities that are less subjective,
such as the ability to drive a car, or to not have covid, or be of a certain
nationality, or that one guarantees a product sold, we cannot just trust
anyone to do that. As individuals or companies we have no clue at a global
scale about who can give out such certificates.

But again that does not mean we have centralisation.
There may be many doctors or places that can give out a vaccination certificate
in a particular town. DMV licences could be given out by a number of organizations.
My buying a product with a warrantee from a particular company does not mean others
don’t make similar products, that I could have also used. But the warranty tells
me that they are responsible for some aspects of the product after the transaction.

> Another solution is chaining: have an accreditation authority issue a VC to issuers, attesting to the issuer's bona fides; verification = verify proximate VC + VC that makes proximate issuer trustworthy. Possibly repeat through several levels of indirection. This still centralizes trust (in the ultimate accreditation parties), but at least it decentralizes the verification.

In a way that is what the Web of Nations proposal is about. The government of a country 
accredits an institution for making certain types of claims - such as that a company is 
a company on their territory, or that some entity is a regional authority etc…

But no nation controls what other nation-states or federations of such states say. So it 
is not centralized in that sense. These nations are in diplomatic peer to peer relations
just like we are in our local social networks.

> Right now I am more interested in the chaining model, because I think it is more flexible and it reuses our core primitive (VC verification) instead of substituting a different type of lookup. I also think it scales better. But there can be political reasons to use a registry instead.
> 
> Anybody have other basic alternatives?

To get going we certainly need something like ad-hoc lists. 

But those will end up having to be linked together across geographical areas. 
As more and more different types of lists emerge for different types of credentials,
we will need an extensible framework that are designed to be linked together
and some international consensus on ontologies, so that software logic can be
oversee able. 

So I think the WoN proposal is a chaining model and a Web model. There are aspects
of chaining of links, and also the ability to choose one’s trust anchors.


> 
> On Mon, Aug 9, 2021 at 10:14 PM David Chadwick <d.w.chadwick@verifiablecredentials.info> wrote:
> In the TRAIN project we have devised an alternative strategy for trusting VC issuers, based on the existing concept of Trust Lists       as standardised by ETSI. It works like this.
> 
> Every VC that is issued by any issuer, contains a Terms of Use containing the trust scheme(s) that the issuer is a member of (specified as DNS names). These can be true or false statements, it does not matter.
> 
> Any DNS owner can create their own trust scheme and decide which VC issuers are members of it and therefore are trusted to issue VCs of a certain type (with a certain schema). The DNS owner adds a URL RR to their DNS entry containing a TRAIN formatted URL.
> 
> The TRAIN open source code will read this RR, dereference the URL and expect to find an ETSI trust list published at this https URL. It will then check if the VC Issuer is listed in this DNS named trust list, and if so will tell the Verifier that the issuer is a trusted member of this trust scheme operated by this "DNS name". In this way it does not matter whether the issuer was telling the truth or not. The TRAIN API and the DNS Owner tells the verifier the truth.
> 
> Each entry in the trust list has a Service Type Identifier. This is a URL and the web page pointed to should contain the JSON schema (and @context) for the VCs that are issued for this Service Type. In this way the verifier can also find out which attributes the issuer is trusted to issue.
> 
> All the verifier has to do is configure the DNS names of the trust scheme owners that it trusts. When it receives a VC, it extracts the asserted trust schemes made by the issuer in the ToU property, and calls the TRAIN API, passing it the ID of the issuer and the trust scheme it is a member of. The TRAIN API will then check if the VC Issuer is a member of this trust list, and if so return the Service Type URL to the Verifier, so that the verifier can validate that the attributes in the received VC match the schema for the Service Type.
> 
> Note that the TRAIN source code can be run by anyone, so there can be multiple distributed copies of this service running on the Internet, and verifiers only need to keep pointers to one or more of them to provide them with backup services (much like the dozen or so root DNS name servers).
> 
> Kind regards
> 
> David
> 
> On 04/08/2021 22:59, Henry Story wrote:
>>> On 4. Aug 2021, at 23:33, Bob Wyman <bob@wyman.us>
>>>  wrote:
>>> 
>>> I think one of the points of Henry's post was that interpretation of a statement depends, at least in part, on knowing the specific legal context within which the statement is made. In focusing on domain names, I confused matters because we all know too much about them. The point is that we can't know all the data that every country's equivalent of Companies House might publish and we can't know which of the statements made are authoritative rather than simply repetitions of self-asserted information that should be further verified. Thus, any automated means is going to need some indication, for each legal context, of what statements are authoritative and which are not. Is that reasonable? If so, how would an automated means discover the differences?
>>> 
>> There are I am sure a number of ways of doing that. Before the VC group produced its work I would have tried
>> to think hard about doing this without using named graphs or signatures.  But why not use those, now that those
>> are established?
>> 
>> 
>>> How useful would it be to have the maker of a statement annotate it with a claim as to whether or not the statement was authoritative? If so, what would be the requirements for expressing such a claim of authority or its absence? (a meta-VC?) How could proof of authority be provided?
>>> 
>> I think that would be very useful.
>> 
>> A record for my company could be published in two graphs published as a single DataSet in JSON-LD
>> available using HTTP (and perhaps also in some archived form on a LinkedData blockchain)
>>  * one part signed by company house,
>>  * the other part may not require a signature at all, or be signed by my company somehow.
>> 
>> The Companies house WebID or DID would link to 
>> https://gov.uk/registries
>>  and that would 
>> link back to the digitized registrars on the UK territory. That two way link (chain) provides
>> the proof of authority for UK Citizens whose trust anchor is the UK.
>> 
>> French citizens on the other hand, would need another link in the chain of trust: namely one from
>>  
>> https://registres.gouv.fr/ to https://gov.uk/registries
>>  
>> 
>> That is: the WoN is a non-centralised (diplomatic) social network that allows agents from
>> different countries to be able to evaluate claims of authority across national boundaries,
>> and have some estimation of the legal spaces involved. 
>> 
>> Of course Legal systems don’t make illegal behavior impossible, they just provide means of
>> finding redress if such happen that is strong enough to encourage a default trusting behavior. 
>> 
>> Henry
>> 
>> 
>> 
>>> bob wyman
>>> 
>>> 
>>> On Wed, Aug 4, 2021 at 5:09 PM David Chadwick 
>>> <d.w.chadwick@verifiablecredentials.info>
>>>  wrote:
>>> 
>>> 
>>> On 04/08/2021 20:44, Bob Wyman wrote:
>>> 
>>>> David,
>>>> I don't doubt that mechanisms can be provided to validate all the statements that might be made by Companies House, I was just pointing out that for some stuff I would trust Companies House and for other statements they make I would take those statements as things I should validate elsewhere -- unless they could show me a VC that indicated that they had already done the validation with the appropriate third-party. What I need is a means to determine which statements by Companies House should be considered the "final word" and which are statements that should be investigated further, perhaps by seeking an EV PKC. 
>>>> 
>>>> Perhaps I'm reading Henry's stuff wrong, but it seems to me that he's talking about providing a means by which I can determine a site's position within a specific legal context, such as that of a country. Thus, using Henry's proposed ontology, I could discover that Companies House provides the function of "incorporating and dissolving limited companies" in the context of the UK legal system. That is useful. However, it seems to me that I then need to do a "reverse search" to figure out, given the UK legal environment, "Who is the authority for domains (or whatever) mentioned in Companies House statements?" If the answer is "Companies House," I'm done. But, if it isn't, I need to do more work.
>>>> 
>>> I am afraid you will need to do more work, because the scope of Companies House does not intersect with the scope of the DNS and IANA. In other words, there is no relationship between a DNS name and a company's legally registered name. This is what EV PKCs were designed to do, to bridge that gap.
>>> 
>>> Kind regards
>>> 
>>> David
>>> 
>>> 
>>>> Please accept my apologies in advance if this is a really dumb question. I'm trying to catch up.
>>>> 
>>>> bob wyman
>>>> 
>>>> On Wed, Aug 4, 2021 at 3:06 PM David Chadwick 
>>>> <d.w.chadwick@verifiablecredentials.info>
>>>>  wrote:
>>>> We have been working on this problem for a while now and we have a working solution. It involves VCs and EV PKCs. CAs already issue DV PKCs instantly because the applicant can prove ownership of the DNS name, but it stops there. For EV PKCs you need to provide paper documents and perhaps answer telephone enquiries to prove ownership of the company name as well. In our working demo, a CA will instantly issue an EV PKC to an applicant if the applicant can provide VCs to prove its details from Companies House, its bank account details from a bank, its director's passport details etc. Of course, these VCs are not yet available from these issuers, but if they were, of if we had a trusted attribute attestation service instead that the CA trust, then we could issue EV PKCs instantly and the applicant organisation could prove ownership of the DNS name and the Company name using existing trust infrastructures
>>>> 
>>>> Kind regards
>>>> 
>>>> David
>>>> 
>>>> On 04/08/2021 19:38, Bob Wyman wrote:
>>>> 
>>>>> Henry,
>>>>> In your example blog post, Stopping (https) phishing, it seems that one could reasonably assume that 
>>>>> companieshouse.gov.uk is a reliable authority concerning much about UK limited companies. Given a to-be-defined, ontology, etc. I understand how my browser might come to accept that. However, it isn't obvious to me that I should trust all that companieshouse.gov.uk
>>>>>  has to say about UK limited companies. For instance, in your example, you have:
>>>>> "company_name": "CO-OPERATING SYSTEMS LTD.",
>>>>> 
>>>>>   "date_of_creation": "2015-12-17",
>>>>> 
>>>>>   "domain": ["co-operating.systems","
>>>>> www.co-operating.systems
>>>>> "], 
>>>>> 
>>>>> While I might trust this site's statement about the company name and date of creation, because their purpose is to "incorporate and dissolve limited companies" (a function that exists in many legal systems and thus something that could be usefully named.), why would I trust statements they make in their role of "register[ing] company information and mak[ing] it available to the public?" It seems to me that much of that data may be self-assertions by the registered companies and may not have been verified by anyone. For instance, unless they operate domain registries, why would I believe statements about what domains are owned, operated, or controlled by a company in their lists?
>>>>> 
>>>>> It seems to me that I need a way to discover not only the legal provenance and role of 
>>>>> companieshouse.gov.uk
>>>>>  but also some means to distinguish which of its claims can be considered authoritative and which cannot. Is this reasonable?
>>>>> 
>>>>> bob wyman
>>>>> 
>>>>> 
>>>>> On Wed, Aug 4, 2021 at 11:56 AM Henry Story 
>>>>> <henry.story@gmail.com>
>>>>>  wrote:
>>>>> Hi all,
>>>>> 
>>>>> There is a need for a global, decentralised, geopolitically relevant trust system
>>>>> that reflects international law. It is not technically difficult to do, all the
>>>>> pieces are in place, and it is needed for a lot more than Verifiable Claims.
>>>>> 
>>>>> I wrote this up a couple of years ago as part of my 2nd year PhD 
>>>>> report (on hold  as I ran out of money), and summarized it in this PDF.
>>>>> It’s a real simple application of linked data
>>>>> 
>>>>> 
>>>>> https://co-operating.systems/2020/06/01/WoN.pdf
>>>>> 
>>>>> 
>>>>> I have not had time to translate that doc to HTML, but  it actually points to 
>>>>> a number of earlier blog posts all in HTML. For example this blog post
>>>>> describing 13 use cases
>>>>> 
>>>>> 
>>>>> https://medium.com/@bblfish/use-cases-for-the-web-of-nations-361c24d5eaee
>>>>> 
>>>>> 
>>>>> Perhaps that can be brought into the consultation process?
>>>>> 
>>>>> Henry
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 4. Aug 2021, at 17:30, David Chadwick <d.w.chadwick@verifiablecredentials.info>
>>>>>>  wrote:
>>>>>> 
>>>>>> All verifiers should be able to be configured with Issuers that they trust. So configuring with *.gov.country should be a viable option for a verifier. In this case a trust list is not needed because you already know your trusted issuers.
>>>>>> 
>>>>>> If you want to have a trust chain that goes from gov.country to unknown.issuer to 
>>>>>> holder.vc
>>>>>>  that is also fine because you an unbroken chain of trust, effectively with delegation of authority from gov.country to the unknown.issuer. But this is somewhat different to an attribute attestation service. Its an issuer attestation service (regardless of the attributes the unknown.issuer asserts). So lets not mix up concepts.
>>>>>> 
>>>>>> Kind regards
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> On 04/08/2021 10:06, Steve Capell wrote:
>>>>>> 
>>>>>>> Not sure that you need a published trust list in all cases.  As you suggest, if both issuer and attestation provider are equivalently “unknown” then there’s little value.  But that’s rarely the case.  The whole point of attestations is that they are made by rusted parties.  For example 
>>>>>>> - a national health authority attests to the accreditation status of an otherwise unknown clinic that issues a vaccination cert
>>>>>>> - a customs authority attests to the business identity and trusted trader status of an otherwise unknown issuer of a declaration of origin 
>>>>>>> - and so on 
>>>>>>> 
>>>>>>> In these cases I really only care that the attestation comes from *.gov.au or *.
>>>>>>> gov.uk
>>>>>>>  . I Don’t really need a list to check that Australia or the United Kingdom governments exist or to decide whether to trust them - do I?
>>>>>>> 
>>>>>>> Steven Capell
>>>>>>> Mob: 0410 437854
>>>>>>> 
>>>>>>> 
>>>>>>>> On 4 Aug 2021, at 6:43 pm, David Chadwick <d.w.chadwick@verifiablecredentials.info>
>>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hi Luca
>>>>>>>> 
>>>>>>>> This makes more sense. Simplify is more correct than shorten. But it is still a spurious argument.
>>>>>>>> 
>>>>>>>> This is because you are comparing apples and oranges. You are saying that if we get an issuer we don't recognise then it is complex to resolve this, so the holder should replace the issuer with an attribute attestation service that we do recognise. But what if you don't recognise the attribute attestation service that the holder has used to replace the issuer (e.g. one from Somewherestan). You have solved nothing. An unknown issuer and an unknown attribute attestation service are just as value-less, whilst a known issuer and a known attribute attestation service may be just as valuable to the RP.
>>>>>>>> 
>>>>>>>> So using an attribute attestation service is only of value if the RP (or EU) publishes the list of trusted issuers (which can include genuine issuers and attribute attestation services, as the two are indistinguishable from a trust perspective (unless the trust list describes the differences)) and tells the users that they must get VCs from issuers in this trusted list otherwise the RP wont be able to interact with them.
>>>>>>>> 
>>>>>>>> I think your comment really boils down to the fact that trust lists are really needed (which is exactly what the TRAIN project has produced, as part of eSSIF-lab).
>>>>>>>> 
>>>>>>>> Kind regards
>>>>>>>> 
>>>>>>>> David
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 03/08/2021 07:21, Luca Boldrin wrote:
>>>>>>>> 
>>>>>>>>> Correct, Steve.
>>>>>>>>> In general, “shorten” should perhaps be replaced with “simplify”. 
>>>>>>>>> Indeed, validating a credential issued by an unknown issuer requires a complex process of gathering information about that issuer (when available), and taking risk-based decisions.
>>>>>>>>> In the “qualified attribute attestation” model you just check that the attester is listed in the EU trust list, liability is clear.
>>>>>>>>> The model has drawbacks as well…
>>>>>>>>> Best,
>>>>>>>>>  
>>>>>>>>> --luca
>>>>>>>>>  
>>>>>>>>>  
>>>>>>>>>  
>>>>>>>>> Da: Steve Capell 
>>>>>>>>> <steve.capell@gmail.com>
>>>>>>>>>  
>>>>>>>>> Inviato: martedì 3 agosto 2021 02:28
>>>>>>>>> A: David Chadwick 
>>>>>>>>> <d.w.chadwick@verifiablecredentials.info>
>>>>>>>>> 
>>>>>>>>> Cc: 
>>>>>>>>> public-credentials@w3.org
>>>>>>>>> 
>>>>>>>>> Oggetto: Re: Public consultation on EU digital principles
>>>>>>>>>  
>>>>>>>>> ATTENZIONE: Questa e-mail proviene dall'esterno dell'organizzazione. Non cliccare sui link o aprire gli allegati a meno che tu non riconosca il mittente e sappia che il contenuto è sicuro.
>>>>>>>>> I assumed that it meant a shorter trust chain from the verifier perspective  
>>>>>>>>>  
>>>>>>>>> For example 
>>>>>>>>> - option 1: clinic issues covid cert to subject.  Health authority issues accreditation cert to clinic.  There is some kind of hash link connection from covid vax cert to clinic accreditation cert.  verifier must follow links and verify both
>>>>>>>>> - option 2: clinic does covid jab and requests certificate issuing directly from national authority
>>>>>>>>> (Oracle as issuer pattern).  Verifier just verified the one cert and trusts the national authority 
>>>>>>>>> 
>>>>>>>>> Steven Capell 
>>>>>>>>> Mob: 0410 437854
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 3 Aug 2021, at 6:11 am, David Chadwick 
>>>>>>>>> <d.w.chadwick@verifiablecredentials.info>
>>>>>>>>>  wrote:
>>>>>>>>> 
>>>>>>>>>  
>>>>>>>>> Hi Luca
>>>>>>>>> 
>>>>>>>>> I am interested to know how the introduction of an attribute attestation service, presumably between the issuer and holder, can shorten the trust chain. One would have thought that it would do the opposite
>>>>>>>>> 
>>>>>>>>> Kind regards
>>>>>>>>> 
>>>>>>>>> David
>>>>>>>>> 
>>>>>>>>> On 02/08/2021 17:43, Luca Boldrin wrote:
>>>>>>>>> Hi Manu,
>>>>>>>>> the consultation is an online survey that anyone can fill in. In parallel the EU Commisison is conducting many one-to-one discussions with different stakeholders.
>>>>>>>>> One of the most relevant aspects under discussion is probably related to “attribute attestation service”, which is a trusted third party acting on behalf of the issuer (to shorten the trust chain):
>>>>>>>>> <image002.jpg>
>>>>>>>>> (from 
>>>>>>>>> https://ec.europa.eu/newsroom/dae/redirection/document/76608
>>>>>>>>> )
>>>>>>>>>  
>>>>>>>>> I would appreciate any views on that.
>>>>>>>>> Best,
>>>>>>>>> --luca
>>>>>>>>>  
>>>>>>>>>  
>>>>>>>>> Da: Snorre Lothar von Gohren Edwin 
>>>>>>>>> <snorre@diwala.io>
>>>>>>>>>  
>>>>>>>>> Inviato: lunedì 2 agosto 2021 15:00
>>>>>>>>> A: Manu Sporny 
>>>>>>>>> <msporny@digitalbazaar.com>
>>>>>>>>> 
>>>>>>>>> Cc: W3C Credentials CG 
>>>>>>>>> <public-credentials@w3.org>
>>>>>>>>> 
>>>>>>>>> Oggetto: Re: Public consultation on EU digital principles
>>>>>>>>>  
>>>>>>>>> ATTENZIONE: Questa e-mail proviene dall'esterno dell'organizzazione. Non cliccare sui link o aprire gli allegati a meno che tu non riconosca il mittente e sappia che il contenuto è sicuro.
>>>>>>>>> Has anyone attended these or done any consultation? 
>>>>>>>>> Any specific parts that was addressed?
>>>>>>>>> ᐧ
>>>>>>>>>  
>>>>>>>>> On Thu, Jul 8, 2021 at 4:18 PM Manu Sporny 
>>>>>>>>> <msporny@digitalbazaar.com>
>>>>>>>>>  wrote:
>>>>>>>>> For those that don't know about it yet, the EU has opened a consultation,
>>>>>>>>> running through Sept 2021, to get input on future EU digital principles. Folks
>>>>>>>>> that have an opinion (I expect many in this group) may want to join and
>>>>>>>>> provide input.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> https://digital-strategy.ec.europa.eu/en/news/europes-digital-decade-commission-launches-consultation-and-discussion-eu-digital-principles
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- manu
>>>>>>>>> 
>>>>>>>>> -- 
>>>>>>>>> Manu Sporny - 
>>>>>>>>> https://www.linkedin.com/in/manusporny/
>>>>>>>>> 
>>>>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>>>>> News: Digital Bazaar Announces New Case Studies (2021)
>>>>>>>>> 
>>>>>>>>> https://www.digitalbazaar.com/
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>  
>>>>>>>>> -- 
>>>>>>>>> Snorre Lothar von Gohren Edwin
>>>>>>>>> Co-Founder & CTO, Diwala
>>>>>>>>> +47 411 611 94
>>>>>>>>> 
>>>>>>>>> www.diwala.io
Received on Tuesday, 10 August 2021 10:08:30 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 10 August 2021 10:08:33 UTC