Re: WoN Re: Public consultation on EU digital principles

I prefer to use the following wording instead:

white lists -> allow-list
black lists -> deny-list / block-list

See also:
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

OS

On Thu, Aug 12, 2021 at 8:27 AM David Chadwick <
d.w.chadwick@verifiablecredentials.info> wrote:

>
> On 11/08/2021 00:04, Bob Wyman wrote:
>
> David Chadwick 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.
>
> Are these "Trust Lists" semantically limited to expressing only "trust?"
> Is there a way to use trust lists to express a lack of trust? In other
> words, are TL's only white-lists but not black-lists?
>
> Yes I believe they are white lists. Using black lists is flawed anyway,
> since it is impossible to list the infinite number of untrustworthy
> entities.
>
>
> 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.
>
> In your scheme, what value is provided by requiring the fetching of a DNS
> RR rather than just making the ETSI trust list available at some URL, such
> as a /.well-known/ URL on the relevant domain?
>
> This is how the RR looks like in the DNS Zone manager for the current
> implementation.
>
>
>
> _scheme._trust.domain-registers.vc.train.trust-scheme.de.       0
> IN      PTR     _scheme._
> trust.domain-registers-vcscheme.vc.train.trust-scheme.de.
>
> _scheme._trust.domain-registers-vcscheme.vc.train.trust-scheme.de.      0
> IN      URI     10 1
> https://tspa.trust-scheme.de/tspa_train_domain/api/v1/scheme/domain-registers-vcscheme.vc.train.trust-scheme.de
>
>  Kind regards
>
> David
>
>
> Daniel Hardman wrote:
>
>> 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.
>
> If it is discovered, through some arbitrary means, that some intermediary
> in a chain should not be considered trustworthy, even though that
> intermediary produces credentials that satisfy the specification's
> requirements, how can a lack of trust be expressed, communicated, etc?
>
> bob wyman
>
>
> On Mon, Aug 9, 2021 at 4:12 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> <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> <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> <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> <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> <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> <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> <steve.capell@gmail.com>
>> Inviato: martedì 3 agosto 2021 02:28
>> A: David Chadwick <d.w.chadwick@verifiablecredentials.info> <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> <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> <snorre@diwala.io>
>> Inviato: lunedì 2 agosto 2021 15:00
>> A: Manu Sporny <msporny@digitalbazaar.com> <msporny@digitalbazaar.com>
>> Cc: W3C Credentials CG <public-credentials@w3.org> <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> <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 94www.diwala.io
>>
>>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>