- From: Henry Story <henry.story@gmail.com>
- Date: Mon, 16 Aug 2021 09:46:10 +0200
- To: Chris Gough <chris.gough@gosource.com.au>
- Cc: Steve Capell <steve.capell@gmail.com>, daniel.hardman@gmail.com, David Chadwick <d.w.chadwick@verifiablecredentials.info>, Bob Wyman <bob@wyman.us>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Hi Chris, I completely agree with what you wrote below. I just thought I’d elaborate a bit on it. > On 12. Aug 2021, at 10:40, Chris Gough <chris.gough@gosource.com.au> wrote: > > Hi, thanks for looping me into the conversation Steve. > > I think the idea that the chaining model centralises trust is slightly wrong. There doesn't have to be one accreditation authority (that issues a VC about an the issuer, cited by the issuer) there could be many - how to interpret that is actually a policy of the verifier, not something that can be imposed on them (except to the extent they adopt conventions). A VC might contain references to contradictory credentials, or multiple credentials that make correlated claims - none of which are individually convincing, but collectively they allow a level of assurance that passes the threshold of trust. Verification only proves attestations are attributed to the issuer, not that they are true and correct facts - they may prove the issuer was wrong (or telling a lie, or tricked into doing something stupid). The chaining model makes a graph of _reified_ claims, a "single authority" model is only the simplest possible shape of claims graph. Assurance is about darker or lighter shades of grey, it depends on the quality and quantity of information. A binary trust policy (wholy trusting particular claims if they are made by a particular authority) is the trivial case. The verifier is an autonomous agent who is responsible for their own policies. If they have a policy to always trust one "authority" and ignore all else then that's their business, but it's not the only policy they could have. Thanks. That is the basic premise of WoN. There can be any number of trust anchors people can use. And it is quite easy to see that this is how things work at national levels. I started describing how Linked Data publication of claims by registrars could be used by browsers to enhance the information about a web site someone had reached. This would allow the browser on reaching https://facebook.com.trust.me to show either a warning sign because of complete lack of information about the owners of that web site on first reaching it, or show information from a registrar in the wrong country, or with the wrong owners and market cap. Or imagine that someone comes across a story on https://washington-news.com about some scandal involving pizza. Knowing that the site is run by a company in Albania, should help people get a better feeling on how to assess the story. They may still look at it and comment on it, but with the legal context visible to all, the effect of a smiley by one person who understood the context, being misunderstood as a like by someone who is not aware of the context is reduced, and at least need not reach viral proportions. > > If Steve issues a VC saying "it's raining today in Canberra", and I issues a VC saying "it's sunny today in Canberra", you might issue a VC that cites both ours saying "it's probably raining in Canberra today" given your issuer-policy that Steve is a reliable weatherman I'm a habitual liar. (it's not by the way, it was a lovely day). Your verifier might make weather-related decisions because they trust you (and don't know anything about Steve or me, or how you come about your weather predictions), or they might ignore what you and I have to say and just look at what Steve said. All the VC can ever do is present (a graph of) attributed attestations. Yes, so I might end up with an attestation that https://facebook.com.trust.me is a company in Macedonia, that it is 1 years old, and that it has 100 euros to its name, and that it has no further information. That is we should think of well informed humans as being able to make decisions too. This is nearly completely overseen because of the poverty of information in existing X509 certificates! Humans can make trust decisions, but not with at minimum a name, or at most a static text address. > > Another example, imagine the Government of the Moon issuing a VC that says "we are satisfied this person complies with our vaccination and testing policy, they do not represent a biosecurity hazard which would prevent them entering our exclusive economic zone", and that VC chains to lab test results, which in turn chain to a lab certification credential. The verifier might guess this means that the lab certification contributed to the Moon's entry policy being met, but that's not necessarily true (if the policy is opaque, the verifier doesn't know what other information contributed to the decision, or how the chained information was interpreted. Maybe they just bribed the official, and the lab certification is actually about something to do with avocados). There are cases where issuer policy will be opaque and cases when it will be transparent, there will be cases where extrinsic data is used in the decision to issue and cases where the issuing policy is strictly based on intrinsic (chained) data. The verifier will always be free to use the information however they want. Indeed. And there are people with completely legal, non-faked passports, that cannot enter a country, because the two countries happen to be at war or close to that. That brings up that there is some interesting reasoning a client can follow before sending a credential to a web site, which is a form of modal reasoning. A client could read the Policy for access to a resource and work out what types of trust anchors the server has and work out whether presenting a credential - even a valid one - will be enough to convince the server resource guard. That is the client wants to try to answer: will the Server believe my Credential to be valid and acceptable before I send it? That is independent of the truth of the claim. Attackers of course also use such doxastic modal reasoning. They tend to ask: is there any ”proof” I can conjur up cheaply enough that will convince the guard to let me in. And they try to model the software flaws of the targeted system too. Fun stuff. > In the above scenario, the Government of the Moon is doing a great service by issuing their VC. They are freeing the verifier from having to know or care what the Moon's policy is. Even if the moon has a public and deterministic policy function whose inputs are all present in the claim graph, I don't want to be responsible for correctly implementing their policy if the only information I care about is the function's output. But I'm very glad their policy is transparent and their working is fully accountable, that's nice too. I might be responsible for organising travel between hundreds of independent spaceports; even if it seems easy to implement policy functions for each of them, how can I be sure their policy hasn't changed since last time I checked? I don't want to depend on a stinking policy register. Even an issuer with public and deterministic policy based on intrinsic data is providing a potentially useful abstraction. One verifier policy might be to trust that the issuer correctly knew and implemented their own issuer-policy at the time of issuance, freeing them from having to know it. Another verifier of the same credential might make their own assessment of the correctness of the issuer policy implementation, and hold them to account when they deviate. The community of verifiers of the second type reduces the risk to the community of verifiers of the first type. I like the Government of the Moon use case :-) Yes, I think people will want to stabilize to a point where the reasoning about what credentials other actors will accept is mostly deterministic, even if there is no one objective view. So a web browser before building a credential should be able to work out that certain types of age credentials will be accepted by a US web site and not others, even if those are accepted elsewhere. > > The detective says Rasputin was shot, stabbed, poisoned and thrown into an icy river. I suspect foul play. Somone both a. killed Rasputin b. intended the above to send a message A Gricean communication action. > Chris Gough > > On Tue, 10 Aug 2021 at 23:12, Steve Capell <steve.capell@gmail.com> wrote: > I prefer the chaining model too > > Sone verifiers might prefer not to advertise who they trust as that is their internal risk profiling job. Advertising who you trust is a bit like telling Malik which mask to wear to the masquerade party > > Hopefully doing some cross border trading pilots soon - using the linked credentials trust chain model > > Steven Capell > Mob: 0410 437854 > >> On 10 Aug 2021, at 6:52 pm, 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... >> >> 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. >> >> 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. >> >> 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? >> >> 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 > > > -- > Chris Gough > > GoSource > office: +61 2 61983268 > mobile: 0431 626961 > > > --- > The content of this email and attachments are considered confidential. If you are not the intended recipient, please delete the email and any copies, and notify the sender immediately. The information in this email must only be used, reproduced, copied, or disclosed for the purposes for which it was supplied.
Received on Monday, 16 August 2021 07:46:29 UTC