# Control your digital you on the web
and be a verifiably authentic source of information

---

Goal: to increase interest in implementing a did:webs
Target: people who are dissatified with did:web and have enough at stake to need 100% security. The target group may also have an allergy to ledgers.
USP: separation of authorisation of your identifier and domain control. No longer dependent on domains.

---

{Useful notes:
Charles Lanahan (23 Feb 2024, 15:46)
no longer dependent on domains or certificate controllers

You (23 Feb 2024, 15:46)
+1
Organisational identity security}

**Q. What is the most annoying thing about the increasingly digitizing world?
A. You're not in control.
Q. What is the second most annoying thing...?
A. That you're constantly put to work by centralised powerhouses: you have to clean up their mess on their servers. So the fact that it's about your personal information (as in 'information that describes you and represents you') is irrelevant.
Q. What is the third most...?
A. They threaten you constantly if you don't obediently do "your job", thereby reversing the burden of proof, hiding anonymously behind rules and regulations, and presenting deadlines and ultimatums.**

Who are "they"? | TBW |

It's about time you took control of your digital you on the web.

The crux of this article is: To take control we must use did:webs. I can't tell or show you why that is: the did:webs protocol is too complex. You won't believe me: you might not have felt the pain yet.
This write up wants you to start implementing did:webs because this is our 'puppy-dog' approach { explain puppy dog and that did:webs is our puppy }: once you look did:webs in the eyes you'll never let go of it.

| TBW an example / scenario NOT analogy | Interop profile
{Here's the minimum interop profile of did:webs}

### Did:web – without the 's'

DIDs are a great novelty for the world. One of the most popular is `did:web` because of its simplicity and reuse of internet and web infrastructure.

{What linkage } That linkage to existing web infrastructure has major drawbacks:
- no control authority
- your identifiers are dependent on domains
- your reputation is dependent of SSL/TLS renewal
- the web is not secure: you cannot tell who said what.

### Who have been implementing `did:web` so far?

> chatGPT answers:
> The `did:web` method is a decentralized identifier (DID) specified by the World Wide Web Consortium (W3C). It allows DIDs to be created within the domain name system of the web. This enables people to prove control over a domain while using that domain to host their DIDs. Therefore, verifiable, self-sovereign digital identities can be directly linked to existing web infrastructure.

> Several organizations and projects have been implementing or experimenting with did:web for various use cases, including:
> - Governmental and Public Sector Initiatives: Some governmental and public sector projects have explored did:web for digital identity systems, aiming to provide citizens with secure, self-sovereign identities.
> - Educational Institutions: Universities and educational bodies have implemented did:web to issue verifiable credentials, such as diplomas and certificates, directly linkable to their domain names, enhancing the authenticity and verifiability of academic qualifications.
> - Companies and Enterprises: Businesses in sectors like finance, healthcare, and supply chain management are implementing did:web to improve identity verification processes, ensure data integrity, and enhance user privacy.
> - Open Source and Decentralized Projects: Various projects within the blockchain and decentralized technology space are adopting did:web to provide users with more control over their digital identities, integrate with decentralized applications (DApps), and support interoperability across different platforms and services.
> - Individuals and Developers: Developers, technologists, and privacy advocates are also using did:web to experiment with self-sovereign identity concepts, create personal identifiers, and develop tools and libraries that support the broader adoption of DIDs.

Technology will always grow and will always be adopted more widely. But there's also a back lash or, at least, dissatisfaction with did:web because:
1. You're not really in control of your `did:web` identifiers
2. People dislike ledgers for storing their digital twin
3. Of its dependence of domains.

### Did:webs – with the 's'

's' stands for *security*. KERI is the operator of authenticy behind did:webs. It doesn't need the current web infrastructure to deliver verifiable authenticy. Moreover, the current (X.509-protocol based) web infrastructure can't keep up with the security characteristics KERI offers.

The specific details of KERI's security model are beyond the scope of this article. Besides security, there are great spin-offs from involving KERI in did:webs. But, before we go into those advantages, one main concept needs to be clear from the outset. Fasten your seatbelts!

## The difference between authenticity and veracity

Or, between 'who said what?' and 'is it true what's been said?'

{explain credentials the way Cambridge does in two ways}

### Veracity

This is always a *personal assesment* based on collected verifiable credentials, the reputation judged by the receiver:

> Example
> Has the restaurant's food improved?
> To answer this question you might collect data from various sources and even go there for lunch yourself and read reviews of others visiting the place. It's subjective because whatever is important to you for assessing that a restaurant has improved is a very personal judgement. And also, what are the credentials of your respondents? There's no algorithm that can calculate complex veracity questions, and most judgements have many non-binary parameters.

### Authenticity

The authenticity or 'who said what' challenge is quite different in nature. Using KERI infrastructure authenticity of content can be cryptographically verified to the *root-of-trust* of a digital identifier.

Example: libsodium KLI salt command

This is an example of a one-way function. If you use the so-called salt, you won't be able to re-generate it from the result you've produced with it, conversely, if you have control over the salt, you can cryptographically proof that the result has been produced with it.

### Spin off using did:webs

- True Self Sovereignty. The biggest eye-opener for Darrell O'Donnell {role, organisation} was "the fact that control over my identifier was completely separate from the domain I am on".
- Relaxed key management