Something went wrong. Try again.
ocaml
Something went wrong. Try again.
6.1 kB · 45 lines
at pp-ast
12345678910111213141516171819202122232425262728293031323334353637383940414243444546\title{Survey of global identification schemes}\author{jonmsterling}\date{2025-03-08T15:53:14Z}\p{There are several extant schemes for identifying individuals, organisations, and artefacts. Some are centralised, and others are decentralised. Centralisation of identity is not necessarily a bad thing, but it is most viable when nearly everyone agrees on the central authority; on the other hand, decentralisation can help in situations where a single central authority has not accumulated enough trust or prestige to be viable.}\subtree[OYOM]{ \title{Centralised identification via DOIs and ORCIDs} \p{Nearly every scholarly paper and book published has a \em{Digital Object Identifier} (DOI) assigned to it, which are managed by a single authority ([The DOI Foundation](https://www.doi.org/)); this applies to both traditional publishers and eprint servers like the arXiv. Services like [Zenodo](https://zenodo.org/) allow individuals to mint their own DOIs and pin resources and artefacts to them. Due to their widespread adoption, DOIs are a completely viable way to identify published papers and books—and I would argue that any attempt to replace DOIs with a decentralised identifier is likely to be counterproductive as the goal should not not be decentralisation \em{per se} but rather to have a reliable, universal way to refer to scholarly content and artefacts.} \p{What DOIs do for artefacts, the \em{Open Researcher and Contributor ID} (ORCID) aims to do for \em{people} acting within the framework of open science. ORCIDs seem to do their job well, but not everyone has or should have an ORCID—nor would every person who does have one voluntarily choose to pin their entire identity to it. Therefore, although I happily use them, I think ORCIDs are likely to face more of an uphill battle than the DOI—which needed buy-in only from major publishers and eprint servers to reach hegemony.}}\subtree[OYOK]{ \title{Informal decentralised identification via web addresses} \p{A particularly simple way to identify a single person or organisation is by means of a web domain or an email address. Although not everyone has a domain name, many people have email addresses. On the other hand, people often have many domain names and their email address may change over time; and when people die, their presence on the web is often erased or lost. Therefore, although widespread, this approach may create difficulties with longevity and stability.}}\subtree[OYON]{ \title{General-purpose decentralised identification via DIDs} \p{When reading about the paper of [Klepmann et al.](klepmann-et-al-atproto-2024) outlining Bluesky’s AT Protocol, I learned of [\em{Decentralised Identifiers} (DIDs)](https://www.w3.org/TR/did-1.0/). In essence, DIDs are URIs of the form \code{did:method:path} where \code{method} identifies \em{how} the DID is intended to be resolved and \code{path} is a colon-separated path that should be resolved by means of that method. In either case, a DID is intended to be resolved to a JSON document that contains information about the resource or entity being described, as well as various methods (like public keys) for verifying the integrity of that information. The \em{methods} are somewhat open-ended, but two important methods have emerged.} \subtree[OYOO]{ \title{W3C’s \code{did:web} method} \p{[W3C have specified the \code{did:web} method](https://w3c-ccg.github.io/did-method-web/), which in which the \code{path} is intended to be a web domain. Simplifying somewhat, a DID like \code{did:web:jonmsterling.com} would be substantiated by responding to the HTTPS request \code{https://jonmsterling.com/.well-known/did.json} with a document in the appropriate format. The upside is that the owner of a web domain is \em{their own} identity authority; in this sense \code{did:web} is a truly decentralised identification scheme. The downside is that you have to have a web domain, and you also can never change it ever—the [same disadvantage of informal decentralised identification which we have discussed](OYOK).} } \subtree[OYOP]{ \title{Bluesky’s \code{did:plc} method} \p{For a social network like Bluesky, it is critical that users be able to migrate their identity from one domain to another. Obviously users may change or lose their domain over time, but it is important to keep in mind that the vast majority of users will \em{never} have their own domain and so they will over the course of their lives jump from one subsidiary domain that they don’t control to the next—just as Mastodon users are constantly migrating from instance to instance, driven to wander endlessly by either the petty tyranny of instance maintainers who think they know best, or by the natural quiescence of instances caused by lack of funds or time, or (in many cases) a combination of the two.} \p{It seems that there is no way to address this problem without introducing some central authority—a \em{directory} of permanent identifiers that are then resolved to documents that establish cryptographically verified bidirectional links with more ephemeral and human-readable forms of identification (such as web domains). This is essentially the design of Bluesky’s \code{did:plc} method, as explained by [Klepmann et al.](klepmann-et-al-atproto-2024):} \ol{ \li{On your own domain, which serves as your (ephemeral) handle, you place a DNS TXT record or file that contains a DID like \code{did:plc:asdlkfh9q8034baliufhbcailurb}.} \li{Someone resolves this DID to a document by querying a central \em{directory server} (such as [Bluesky’s own](https://web.plc.directory)). This document contains a link back to the domain; signatures are used to ensure that every update to the document has been authorised by whoever signed it when it was first minted.} } \p{Although some centralisation is required here, the use of cryptographic proof ensures that the central authority does not need to be trusted (to a certain extent).} }}