Re: WoN Re: Public consultation on EU digital principles

Henry,
Yes, if the operator of the domain self-asserts a link to a record at
CompaniesHouse and if the registrant of that record self-asserts a link
back to the domain, I am confident that the domain operator and the
registrant are, or were at some time, either the same entity or two
entities working in concert with each other. However, if I then do a lookup
on the domain and discover that it is registered to EVIL_HACKER LTD. what
should I think? Is it possible that the Companies House data is
out-of-date? Or, that CO-OPERATING SYSTEMS LTD. has some legal relationship
with EVIL HACKER? Should I care what that relationship might be? If there
existed "credibility signals" for EVIL HACKER that differed from those for
CO-OPERATING SYSTEMS, which should I use when presenting data in a web
browser?

bob wyman


On Wed, Aug 4, 2021 at 3:48 PM Henry Story <henry.story@gmail.com> wrote:

>
> > On 4. Aug 2021, at 20:38, Bob Wyman <bob@wyman.us> 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?
>
> Yes, that sounds reasonable.  Data on the registry could be separated into
> two:
>  * one set signed by companies house: such as company creation date,
> declared income, etc…
>  * and another self asserted data that would need to be verified by
> building a linked data
>    chain of trust
>
> How would that work? Why would someone trust the link from my record on
> companieshouse.gov.uk back to my web site https://co-operating.systems/ ?
>
> The simple linked data answer is:
> That link would only be trusted if the site linked back to that record.
>
> So if I tried to link from my companieshouse record to
> https://www.coca-cola.com, that
> would only work if https://www.coca-cola.com linked back to my
> companieshouse.com record.
> That sounds very unlikely, and would also soon be noticed.
>
> To keep this nice and low tech I just proposed doing it by adding a Link
> relation to a
> response
>
> $ curl -I https://co-operating.systems/
> HTTP/1.1 200 OK
> Date: Wed, 04 Aug 2021 19:30:06 GMT
> Server: Apache/2.4.38 (Debian)
> Last-Modified: Tue, 09 Jun 2020 12:49:02 GMT
> ETag: "21f2-5a7a626ec6455"
> Accept-Ranges: bytes
> Content-Length: 8690
> Vary: Accept-Encoding
> Link: <https://api.companieshouse.gov.uk/company/09920845>; rel="registry"
> Content-Type: text/html
>
>
> Note that in the pdf I only present the general problem statement and
> show how it can be answered building on well known standards requiring
> only
> light weight technical infrastructure.
>
> The more general issues you bring up could be answered in many ways,
> including legal
> changes to the status of entities like CompaniesHouse, that might occur
> before,
> during deployment and after deployment, … This evidently requires cross
> disciplinary
> work.
>
> I brought this idea up at the TAG last year
>
>   https://lists.w3.org/Archives/Public/www-tag/2020Aug/0000.html
>
> and got some feedback that they were interested on ideas how to
> pursue it
>
>   https://lists.w3.org/Archives/Public/www-tag/2020Sep/0000.html
>
> A W3C Workshop on the topic involving legal scholars such as Mireille
> Hildebrandt [1],
> UI designers, Linked Data Security folks such as we have on this list,
> folks with
> knowledge of strategic technical geopolitics could be a way to get people
> to think
> through the issues you brought up.
>
>
> Not only could this help identify web sites with rich live data, but it
> could also help
> VC-credential-verification-agents understand if the credential was signed
> by an entity
> legally allowed to sign such claims.
>
> Henry
>
> [1] https://lawforcomputerscientists.pubpub.org
>
> >
> > 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
> >
> >
>
>