Identifier, Attribute, Claim

2.0 What this chapter gives you#

1. You will be able to look at any field in a database table and say whether it is an identifier, an attribute, or a claim, and defend the answer.
2. You will be able to explain why an identifier written on its own, without naming the list it belongs to, is not information at all.
3. You will be able to state the four lifecycle events every identifier goes through, and name the one that causes the most security incidents.
4. You will be able to tell an opaque identifier from a meaningful one, and predict the three ways a meaningful one will eventually rot.
5. You will be able to describe exactly what happens when the same identifier turns up in two separate systems, and quantify the harm.
6. You will be able to store an attribute correctly, with its value, the time it was true, and the party who said so, instead of a bare column.
7. You will be able to take one email address and show a colleague, on a whiteboard, the three different jobs it is doing at once and which two of them it is bad at.
8. You will be able to name Kim Cameron’s seven Laws of Identity from 2005, say which ones the industry actually followed, and say which one is now built into every major sign-in button.
9. You will be able to review an identity schema against a short checklist and find the reuse hazard before it reaches production.

The word “identity” is doing three jobs in most engineering conversations, and the people in the room are usually not doing the same one. Somebody says “we key the account on identity” and means a label. Somebody says “we need the user’s identity” and means a bundle of facts about a person. Somebody says “the identity came from the provider” and means a signed message in which one party told another party something. Those are three different objects. They have different lifetimes, different failure modes, and different legal weight. Running them together is not a naming quibble. It is the root cause of a very large share of identity bugs, including several that have made national news.

This chapter separates them and keeps them separate. The label is an identifier. The fact is an attribute. The statement about the fact, made by somebody in particular, is a claim. Once you can see the three, a great deal of previously confusing behaviour becomes obvious: why your email address is a terrible primary key, why deleting a user account is more dangerous than keeping it, why two anonymous datasets stop being anonymous when you put them next to each other, and why the sign-in button from a large technology company hands your favourite app an address that nobody else has ever seen.

We will use one worked example throughout. A student called Priya Sharma enrols at a school, gets a roll number, gets an email address, grows older, changes her name, leaves, and is replaced by another student. At every stage we will ask the same three questions: what is the label, what is the fact, and who is saying it. By the end of the chapter that example will have produced a small pile of real specification text, real dates, and at least four production incidents that happened to real companies.

Two neighbours to mark and leave alone. The problem this chapter serves is the one described in chapter 1: recognizing a person you cannot see. And the three verbs that operate on the three nouns defined here, which are identification, authentication and authorization, belong to chapter 3, which pulls them apart properly. This chapter is about the nouns.

The plain version#

A school register, a fact, and a note from the nurse#

Imagine a school. It is a real one, with one thousand and forty children in it, and a paper register in the office. The office needs a way to talk about each child without confusion, because there are three girls called Priya and two of them are in the same class.

So the school does the obvious thing. It gives every child a number. Priya Sharma is number 14 in class 9-B. On every form, every mark sheet, every bus list, she is 9-B/14. The number is not a description of her. It does not say how tall she is or what she is good at. It has exactly one job: to point at her and at nobody else. That is the first of our three things. Call it the label.

Now, separately, there are facts about Priya. She was born on the eleventh of April, 2011. She lives at a certain address in Pune. She cannot eat peanuts. She is good at chemistry. Each of these is a property of the child herself, not of the number. If the school changed its numbering tomorrow and made her 9-B/27, she would still have been born in April 2011 and would still be unable to eat peanuts. That is the second thing. Call it a fact about her.

And now the third thing, which is the one people forget. The school office knows she cannot eat peanuts only because somebody told them. To be exact: the school nurse examined her, wrote a card, and put the card in the file, and the card says “9-B/14 must not be given peanuts”, and the card is dated the third of April, 2025, and it has the nurse’s signature on it. The card is not the same thing as the allergy. The card is a statement made by a particular person at a particular time. It could be right. It could be wrong. It could have been right in 2025 and wrong by 2028. It could have been written by the nurse, who knows, or by a classmate playing a prank, who does not. That is the third thing. Call it a note from somebody.

Why the difference is not academic#

Here is what happens when a school mixes them up.

The kitchen prints a list of children who must not be given peanuts. Somebody in the office builds the list by going through the file of cards. Fine so far. Now Priya leaves at the end of the year and moves city. The next year, a new child joins 9-B and the office, wanting to keep the numbers tidy, gives her the free number 14. The nurse’s card from 2025 is still in the file, still says 9-B/14, still says peanuts. The kitchen list is rebuilt. A child who has never been examined by anyone is now on the no-peanut list, and, far worse, the girl who actually has the allergy is not on any list at all, because she is at a different school now with a different number.

Nothing here was a computer error. Nobody typed anything wrong. The mistake was treating the label as though it were glued to the child permanently, when in fact the school handed it to somebody else. The label pointed at Priya in 2025 and at a different girl in 2026, and every note ever written against that label silently changed who it was about.

That single mistake, in various costumes, is responsible for an enormous amount of trouble in real systems, and we will meet it four more times in this chapter with real names and real dates attached.

The label only works inside its own list#

Take the number 14 out of the school and it means nothing. If you walk into the chemist across the road and say “I am 14”, the chemist has no list to look it up in. Even inside the school, 14 on its own is not enough, because there is a 14 in every class. The full label is 9-B/14, and the full label only works because there is exactly one register, in one office, in one school, in one year.

So a label always comes with an invisible companion: the list it belongs to. The list is what makes the label mean one child and not forty children. When you write a label down without saying which list it came from, you have written down half a fact and it will be misread later.

The school knows this instinctively. The bus company that collects the children has its own numbering, because it collects from four schools and needs its own list. Priya is passenger 212 to the bus company and 9-B/14 to the school, and nobody is confused, because everybody says which list they mean. Trouble starts only when somebody writes “14” on a piece of paper that travels between the two organizations.

A fact is only a fact at a moment#

“Priya is fourteen years old” was true on the first of August, 2025. It was not true on the first of August, 2024, and it will not be true on the first of August, 2026. Age is the clearest case, but almost every useful fact about a person behaves this way. Her address is true until she moves. Her surname is true until she changes it. Her class is true until July. Even the peanut allergy has a date on it, because children sometimes grow out of allergies and adults sometimes develop new ones.

A fact recorded without the date it was true is a trap. It looks like information and behaves like a rumour. The school register that says “age 14” with no year attached will be wrong within twelve months and nobody will notice, because there is nothing in the record to check against.

A note is only as good as the person who wrote it#

Three people told the school office three things about Priya. Her mother gave the home address. The nurse wrote the allergy card. Priya herself said she is good at chemistry. These are all notes, and they are all different in strength.

The mother is a good source for the address and a poor source for the chemistry mark. The nurse is a good source for the allergy and no source at all for the address. Priya is the only source for what she enjoys and a weak source for her own date of birth, which really ought to come from the birth certificate.

So a note has two halves that must be kept together: what is being said, and who is saying it. Strip off the second half and you have destroyed most of the value. “Allergic to peanuts” pinned to a noticeboard with no signature is worth much less than the same words on a signed, dated card from the nurse, and a school that files them in the same drawer has thrown away the difference.

The whole worked example in one place#

Here is the school register for our one child, laid out so that the three things are visibly separate.

Read down that table and you can answer three separate questions that people usually smear into one. Who are we talking about: 9-B/14 in the 2025-26 Northgate register. What is true of her: born April 2011, allergic to peanuts. Who says so: the nurse said the allergy on the third of April, and the mother said the address on the twelfth of June.

Those three questions have professional names, and you have now earned them. The label is called an identifier. The fact is called an attribute. The note, complete with who wrote it, is called a claim. Everything else in this chapter is those three words done carefully.

Where the plain version stops being true#

There is no single register#

The school analogy makes it sound as though somewhere there is one master list with one row per child, and everything else is a copy. In real systems there is no such list, and that is not a temporary state of affairs to be fixed by better engineering.

The school has a register. The bus company has a passenger list. The examination board has a candidate number. The bank has a customer number. The state has a national number. Each of these lists was built by a different organization for a different purpose, and none of them can be the master, because none of them contains everybody the others contain and none of them is authoritative about the others’ business.

The honest version: an identifier does not identify a person. It identifies a row in one particular list, and the belief that the row corresponds to a person is an assumption maintained by whoever runs that list. When the assumption breaks, it breaks silently, because the row is still there and still has a number.

The label is not glued on#

The plain version already showed the school handing number 14 to a second child. What the plain version did not say is how normal that is. Reassigning identifiers is not sloppiness. It is often the deliberate policy of a well-run system, because the space of available labels is finite and somebody is paying to keep it tidy.

Telephone numbers are reassigned by design, because there are only so many of them. Email usernames at a company are reassigned when the employee leaves and a new one with the same name arrives. Cloud storage bucket names are released when the bucket is deleted so that somebody else can use the word. In each case the operator made a reasonable choice, and in each case every system downstream that had stored the old label now points at a stranger.

A label that means something is a label that will lie#

The school’s number 9-B/14 carries information: it says the child is in class 9-B. That feels efficient. You can sort by it, you can print class lists from it, you can eyeball a form and spot a mistake.

Then Priya goes up to class 10 and the number is a lie. Either you renumber her, in which case every record ever filed under 9-B/14 is orphaned, or you leave her as 9-B/14 in class 10, in which case the number now says something false and everybody who trusted it is wrong.

This is not a school problem. It is what happens to every identifier that encodes a fact. The fact changes, and the identifier either has to change with it or start lying. There is no third option, and the fact always changes eventually.

Two lists that share a label become one list#

The plain version treated the school register and the bus list as comfortably separate. Suppose instead that the bus company, wanting to be helpful, agrees to use the school’s numbers.

Now anybody holding both files can put them side by side and join them. The school knows Priya’s marks; the bus company knows which stop she gets off at and at what time. Neither file on its own is dangerous. Joined, they say where a named fourteen-year-old girl stands alone on the road at 15:40 every weekday, and neither the school nor the bus company ever decided to publish that.

The join happened because of a shared label. Nobody attacked anything. The two organizations simply agreed on a word, and the moment they did, the wall between their files stopped existing.

A fact and a statement about a fact are different objects#

The plain version described the nurse’s card as a note about the allergy, and left it there. The distinction is sharper than that, and it matters.

The allergy is a property of Priya’s body. It exists whether or not anybody has written it down. The card is a statement, made by a particular person, at a particular time, asserting that the property holds. The card can be forged. The card can be honest and mistaken. The card can have been accurate in 2025 and stale by 2028. The card can be issued by somebody with no standing to issue it.

The honest version: systems never handle attributes. Systems only ever handle claims about attributes. Every “age: 14” in every database in the world is really “somebody asserted, at some point, that the age was 14”, and the value of that record is capped by how good the somebody was and how long ago the point was. When a schema stores the value and throws away the asserter and the date, it has not simplified anything. It has deleted the only two fields that let you decide whether to believe it.

Uniqueness is not one property#

The plain version said the label points at exactly one child. That is three different promises pretending to be one, and real systems keep different subsets of them.

The first promise is that right now, in this list, no two rows share the label. The second is that over the whole history of this list, no label was ever given to two different subjects. The third is that the label means the same subject in some larger world outside this list. The school register keeps the first. It does not keep the second, as the peanut incident showed. It certainly does not keep the third, since the bus company has its own 14.

Almost every identifier bug you will ever debug is somebody assuming a promise that the issuer never made.

The plain version’s tidiest lie#

The tidiest lie in the plain version is the table at the end, with its neat rows. It implies that once you have separated label, fact and note, you are finished.

The honest version: the three categories are not fixed properties of a piece of data. They are roles that the same piece of data plays in different sentences, often at the same time, in the same system, with different correctness requirements pulling in opposite directions. An email address is the standard example and we will spend a long subsection on it below, because the moment one string is doing all three jobs, the requirements of each job break the other two.

The technical version#

An identifier is a label bound to a namespace and a promise#

Start with the sharpest definition in current use. NIST Special Publication 800-63-4, the base volume of the Digital Identity Guidelines, published on 1 August 2025 and superseding SP 800-63-3 of June 2017, defines the term this way in its glossary:

identifier
  A data object that is associated with a single, unique
  entity (e.g., individual, device, or session) within a
  given context and is never assigned to any other entity
  within that context.

Read that definition slowly, because it contains three separate requirements and most schemas satisfy only the first.

The first is that it is a data object associated with a single entity. That is the pointing part, and it is the part everybody implements.

The second is the phrase “within a given context”. This is the namespace. A namespace is the set of names that a single naming authority controls and within which it guarantees uniqueness. Outside the namespace the identifier means nothing, and worse, it may accidentally mean something else. An identifier written without its namespace is not a weak identifier. It is an incomplete one, in the same way that a bare number without units is not a weak measurement.

The third is the phrase “never assigned to any other entity within that context”. This is a promise about the future, and it is by far the most expensive of the three to keep. It says the operator will not reuse the label after the entity is gone. Most systems do not keep this promise, and most engineers assume they do.

The international standard for identity terminology has moved recently and it is worth getting the citation right. For six years the reference was ISO/IEC 24760-1:2019, “IT Security and Privacy - A framework for identity management - Part 1: Terminology and concepts”, second edition, amended by Amendment 1 in 2023. As of August 2026 that edition is withdrawn. It was replaced in September 2025 by the third edition, ISO/IEC 24760-1:2025, which was also retitled: “Information security, cybersecurity and privacy protection - A framework for identity management - Part 1: Core concepts and terminology”. If you cite the 2019 document in a contract today you are citing a withdrawn standard. ISO/IEC 24760 is the reference if you need vocabulary that will survive a procurement argument. It is also behind a paywall, which is the main reason most working engineers quote NIST instead.

Namespace, scope and uniqueness in real systems#

Here are six identifiers you will actually meet, with the namespace that gives each one meaning and the strength of uniqueness the issuer promises. Everything in this table is a promise the operator has published, not an inference.

Three of those deserve their exact wording.

Amazon’s own documentation for general purpose S3 buckets states that they “exist in a global namespace, which means that each bucket name must be unique across all AWS accounts in all the AWS Regions within a partition”, and then, on reuse, that “when a bucket owner deletes their bucket, the bucket name might become available again in the global namespace for anyone to re-create”. It goes further and spells out the consequence: another account “can use the same bucket name for a new bucket and can therefore potentially receive requests intended for the deleted bucket”. As of August 2026 the same page documents an account regional namespace, described as “a reserved subdivision of the global bucket namespace where only your account can create general purpose buckets”, whose names “can never be re-created by another account”. That is a namespace being deliberately narrowed in order to buy back the non-reassignment promise.

The International Telecommunication Union’s Recommendation E.164, “The international public telecommunication numbering plan”, defines the global namespace for telephone numbers, with a maximum of fifteen digits since the 1997 revision, up from twelve before that [UNVERIFIED: the fifteen-digit maximum and the 1997 revision are from secondary sources; the ITU Recommendation text itself was not retrievable]. The current in-force version was approved on 13 February 2026, which is worth checking again before you quote it. Note what the namespace does and does not promise: your number is unique in the world today, and it is emphatically not yours forever.

RFC 9562, “Universally Unique IDentifiers (UUIDs)”, published in May 2024 and obsoleting RFC 4122, defines a 128-bit identifier and a URN namespace for it. Its version 4 fills the value with random bits and buys uniqueness statistically rather than by asking anybody. Its version 7, new in RFC 9562, puts “a Unix timestamp in milliseconds in the most significant 48 bits” and fills “the remaining 74 bits, excluding the required version and variant bits, with random bits”, which produces identifiers that sort by creation time. That is a real engineering trade: version 7 leaks approximately when the row was created, which is a small attribute smuggled into an otherwise opaque identifier.

RFC 9562 also carries four predefined namespace identifiers for name-based UUIDs, which is the cleanest illustration in any specification of the idea that a name needs a namespace before it means anything:

DNS   6ba7b810-9dad-11d1-80b4-00c04fd430c8
URL   6ba7b811-9dad-11d1-80b4-00c04fd430c8
OID   6ba7b812-9dad-11d1-80b4-00c04fd430c8
X500  6ba7b814-9dad-11d1-80b4-00c04fd430c8

Hash the name “priya” under the DNS namespace and under the URL namespace and you get two entirely different UUIDs, which is correct, because “priya” as a hostname and “priya” as a URL are not the same thing.

The identifier lifecycle, and the one transition that hurts#

Every identifier moves through a small state machine. Draw it once and you will find yourself checking every schema against it for the rest of your career.

  [ unallocated ]
        |
        | assign
        v
  [ active ] <----- restore ------+
        |                         |
        |-- suspend ----------> [ suspended ]
        |
        | retire (subject leaves)
        v
  [ retired ]
        |                  \
        | quarantine         \  tombstone
        | period expires       \
        v                        v
  [ unallocated again ]     [ never reused ]
     ^^^^ THE HAZARD          ^^^^ THE FIX

The five transitions, in the vocabulary you should use in design documents:

1. Assignment binds a previously unallocated label to an entity. The only interesting question is whether the label was chosen (username) or issued (account number), because chosen labels arrive with meaning already attached and meaning rots.
2. Suspension makes the identifier temporarily unusable without releasing it. Nothing downstream needs to change.
3. Retirement ends the binding. The entity is gone. The label is not yet anybody else’s.
4. Quarantine is a holding period after retirement, before the label can be reissued. Its length is a policy decision and it is almost always too short.
5. Reassignment binds the label to a second, different entity. This is the transition that produces incidents, because every record anywhere in the world that stored the label is now, silently, about the wrong person.

The alternative to reassignment is tombstoning: retire the label and never issue it again. Tombstoning costs namespace and buys correctness. This is exactly the trade the SP 800-63-4 definition takes when it requires that an identifier is “never assigned to any other entity within that context”.

The reuse hazard, with four real incidents#

The reuse hazard is not theoretical and it is not rare. Here are four documented cases with dates.

In 1938 the E. H. Ferree company of Lockport, New York, a wallet manufacturer, decided to demonstrate that a Social Security card fitted neatly into its product. The vice president and treasurer, Douglas Patterson, used the real Social Security Number of his secretary, Hilda Schrader Whitcher, on the sample card. The wallets were sold through Woolworth stores across the United States. The Social Security Administration’s own history pages record that in the peak year of 1943, 5,755 people were using Hilda’s number, that over 40,000 people in total reported it as their own, and that “as late as 1977, 12 people were found to still be using” it. That is the mirror image of reassignment: one label, many entities, at the same time. The identifier had not changed at all, and it had stopped identifying anybody.

In mid-2013 Yahoo announced that user IDs inactive for at least twelve months would be released and made available to other people, ran a wishlist in July 2013 and handed out claimed IDs in August 2013. New owners promptly began receiving the previous owner’s mail: password reset links, retail receipts, airline confirmations, apartment applications. In late September 2013 Yahoo shipped a “Not My Email” button. The durable engineering outcome was a protocol change. RFC 7293, “The Require-Recipient-Valid-Since Header Field and SMTP Service Extension”, was published in July 2014 by an author at Yahoo, and its abstract states the problem precisely: it defines an SMTP extension “to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender”, which “can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party”. The syntax is small enough to quote in full:

rrvs-param = "RRVS=" date-time [ ";" ( "C" / "R" ) ]

rrvs = "Require-Recipient-Valid-Since:"
       addr-spec ";" date-time CRLF

The “R” or “C” is the no-support action, with reject as the default. An identifier alone was not enough; the specification had to add a timestamp to say which era of the identifier the sender meant.

In India, the reuse window for mobile numbers is a published regulatory figure. In proceedings before the Supreme Court of India in Writ Petition (Civil) No. 699 of 2021, Rajeswari v Union of India, reported on 3 November 2023, the Telecom Regulatory Authority of India stated that once a mobile number “is deactivated for non-usage or disconnected on the request of the subscriber, it is not allocated to a new subscriber for at least a period of 90 days”. Ninety days is the quarantine period in the state machine above. Every service that treats a mobile number as an account identifier is betting that ninety days is long enough, and for accounts that a person touches once a year, it is not.

In cloud infrastructure, as already quoted, AWS documents that a deleted S3 bucket name may be taken by another account in the same partition and may then receive requests intended for the original. Its recommendation is blunt: “Don’t delete buckets so that you can reuse bucket names”, and, if you must stop using one, “we recommend that you empty the bucket and keep it”. That is tombstoning by another name.

Opaque versus meaningful identifiers, and the three ways meaning rots#

An opaque identifier carries no information about its subject beyond the fact of being that subject’s label. A meaningful identifier encodes something: a date, a place, a category, a sequence position.

Meaningful identifiers are seductive. They are readable by humans, they sort usefully, they let a clerk spot a wrong entry, and they let you answer questions without a join. They also rot, and they rot in exactly three ways.

The first way is that the encoded fact changes. The school’s 9-B/14 stops being true when Priya moves to class 10. A national number that encodes gender stops being true when a person’s legal gender changes. A customer number that encodes the branch stops being true when the customer moves.

The second way is that the scheme runs out of space, because the encoded structure eats digits that could have been used for counting. The clearest documented case is the book trade. ISO announced that the thirteen-digit ISBN would become mandatory on 1 January 2007, under ISO 2108:2005, and gave the reason directly: “the very success of the ISBN system, up to now based on 10 digits, has been causing it to run out of capacity”, intensified by “the explosive growth of electronic publishing”. Every system in the publishing supply chain had to be changed on a fixed date because the old identifier had spent its digits on structure.

The third way is that the encoded fact becomes sensitive, and the identifier becomes a privacy problem simply by being quoted. The United States Social Security Number is the textbook case. From its beginning the SSN was “comprised of the three-digit area number, followed by the two-digit group number, and ending with the four-digit serial number”, and, in the Social Security Administration’s own words, “since 1972, the SSA has issued Social Security cards centrally and the area number reflected the state, as determined by the ZIP code in the mailing address of the application”. So for thirty-nine years the first three digits of an American’s SSN leaked roughly where they were living when they applied. On 25 June 2011 the SSA changed the assignment method to randomization, which “eliminated the significance of the highest group number”, froze the published High Group List “in time”, and brought previously unassigned area numbers into use, excluding 000, 666 and 900-999. The stated reasons were to protect the integrity of the number and to “extend the longevity of the nine-digit SSN nationwide” - which is rot type three and rot type two in a single press release.

Set the main families side by side.

Two positive examples are worth naming precisely.

Aadhaar, India’s resident identity number, is described by the Unique Identification Authority of India as “an easily verifiable 12 digit random number”. Not a birth-date number, not a state-coded number: a random one. The programme launched on 29 September 2010 at Tembhli in Nandurbar district, Maharashtra, where Ranjana Sonawane received the first number. UIDAI states that “as on 16th September 2025, the Authority has generated 142.76 crore Aadhaar numbers to the residents of India”, which is about 1.43 billion. A namespace that large with no encoded structure is the deliberate opposite of the pre-2011 SSN.

ORCID, the researcher identifier, is a secure web address containing, in its own documentation’s words, “a 16-digit number that is compatible with the ISO Standard (ISO 27729), also known as the International Standard Name Identifier (ISNI)”, written as 0000-0001-2345-6789 and never shortened, with the final character a check digit computed “in accordance with ISO/IEC 7064:2003, MOD 11-2”, which “must be ‘0’ - ‘9’ or ‘X’, a capital letter X which represents the value 10”. The important design point is that ORCID exists precisely because researchers’ names are unstable: people marry, transliterate, change discipline and share surnames with three hundred other scientists. The identifier is opaque so that the name can change underneath it.

A check digit is not meaning. It is redundancy: it lets you catch a typing error locally without asking the register. An identifier with a check digit and no other structure is still opaque, and that combination is usually the right answer.

An attribute is a value, a time, a source and a confidence#

NIST SP 800-63-4 splits two terms that most schemas run together:

attribute
  A quality or characteristic ascribed to someone or
  something.

attribute value
  A complete statement that asserts an identity attribute
  of a subscriber, independent of format.

The attribute is the slot: date_of_birth. The attribute value is the statement that fills it: born on 11 April 2011. SP 800-63-4 also defines digital identity as “an attribute or set of attributes that uniquely describes a subject within a given context”, which is worth pausing on, because it makes digital identity a property of a context rather than of a person. The 2017 edition, SP 800-63-3, put the same idea as the unique representation of a subject engaged in an online transaction.

A correctly stored attribute has four parts, and the last three are the ones that get dropped.

There is a fifth part that mature systems add: the level of confidence, which is a judgement about how much the source is worth for this particular attribute. NIST expresses this at the level of the whole proofing process rather than the field, through identity assurance levels, which chapter 3 and the proofing chapters in volume II handle properly.

Three practical distinctions follow.

A self-asserted attribute is one where the subject is the source. This is not worthless. For a preferred display name or a favourite language, the subject is the best possible source and any other source would be worse. It is worthless for age when age controls access to something.

A verified attribute is one where the source is a party with standing to know and the checking step is recorded. The passport row above is verified; the row that says only date_of_birth = 2011-04-11 is indistinguishable from a guess.

A derived attribute, sometimes called a predicate, is a computed answer that discloses less than the underlying value. over_18 = true is derived from a date of birth. Releasing the predicate instead of the date is the single cheapest privacy improvement available in most systems, and it is Cameron’s second law in one line.

The time field is not a nicety. The European Union’s General Data Protection Regulation, Regulation (EU) 2016/679, applicable from 25 May 2018, requires under Article 5(1)(d) that personal data be accurate and, where necessary, kept up to date. You cannot demonstrate that a value is up to date if you never recorded when it was true.

A claim is an assertion plus an asserter#

The W3C Verifiable Credentials Data Model version 2.0 became a W3C Recommendation on 15 May 2025. Its terminology section is the cleanest short vocabulary in the field, and it is worth quoting exactly, because every word is load-bearing:

claim       An assertion made about a subject.
credential  A set of one or more claims made by an issuer.
subject     A thing about which claims are made.
issuer      A role an entity can perform by asserting
            claims about one or more subjects.
holder      A role an entity might perform by possessing
            one or more verifiable credentials.
verifier    A role an entity performs by receiving one or
            more verifiable credentials.
entity      Anything that can be referenced in statements
            as an abstract or concrete noun.

Notice that issuer, holder and verifier are defined as roles, not as kinds of organization. The same company can be an issuer on Monday and a verifier on Tuesday. Notice too that subject and holder are separate: the person carrying a credential is not necessarily the person it is about, which is how a parent carries a child’s vaccination record.

Kim Cameron got to the same place twenty years earlier and by a different route. In the 2005 Laws of Identity paper he defined digital identity as “a set of claims made by one digital subject about itself or another digital subject”, and defined a claim, borrowing from ordinary English, as “an assertion of the truth of something, typically one which is disputed or in doubt”. That last clause is the important one. Cameron chose the word “claim” over the word “attribute” precisely because “claim” carries the smell of doubt, and a system that forgets the doubt will believe anything it is told.

Here is a verifiable credential in the shape the 2.0 specification defines, using our student. The domain northgate.example is a reserved example domain under RFC 2606 of June 1999, so nothing here can accidentally point at a real organization.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "id": "urn:uuid:5f2c1a44-9be0-4c17-9a3e-0b3c2d7e1f88",
  "type": ["VerifiableCredential", "SchoolEnrolment"],
  "issuer": "https://northgate.example/issuers/registry",
  "validFrom": "2025-06-02T10:31:00Z",
  "validUntil": "2026-03-31T23:59:59Z",
  "credentialSubject": {
    "id": "urn:uuid:9c81b0de-4d2e-4a51-8e77-2f6b1d94a0c3",
    "enrolledClass": "9-B",
    "rollNumber": "14",
    "dateOfBirth": "2011-04-11"
  }
}

Every one of our three nouns is visible and labelled. The identifiers are the two id fields, both opaque UUIDs. The attributes are the values inside credentialSubject. The claim structure is the envelope: issuer says who is asserting, and validFrom and validUntil say when the assertion is meant to hold. Version 2.0 of the data model renamed these two properties; version 1.1 called the first issuanceDate. In 2.0 the specification states that validFrom represents “the earliest point in time at which the information associated with the credentialSubject property becomes valid”, and notes that if neither property is present the credential “is considered valid indefinitely” - which is a default you should almost never accept.

A proof block normally sits alongside, carrying the issuer’s signature. That is the machinery that makes a claim checkable rather than merely asserted, and it belongs to volume III, which handles signatures and certificates.

Correlation: what happens when one identifier appears in two systems#

An identifier is a join key. That is its whole purpose inside one system, and its whole danger between two.

The Verifiable Credentials Data Model 2.0 says it plainly in section 4.4, in a note headed “Identifiers of any kind increase correlatability”: “Developers are reminded that identifiers might be harmful when pseudonymity is required”, and “Where privacy is a vital consideration, it is permissible to omit the id property.” A W3C Recommendation telling implementers that the correct value for an identifier is sometimes no identifier at all is a strong statement, and it comes from twenty years of evidence.

Some of that evidence, with dates.

In 2000 Latanya Sweeney published “Simple Demographics Often Identify People Uniquely”, using 1990 United States Census summary data. She found that 87 per cent of the population, 216 million people out of 248 million, “had reported characteristics that likely made them unique” when described by five-digit ZIP code, gender and full date of birth. Replacing ZIP with city, town or municipality still left about 53 per cent, 132 million people, likely to be uniquely identified, and even at county level the figure was 18 per cent. The lesson is that you do not need an identifier to get an identifier. Three ordinary attributes, combined, function as one.

On 4 August 2006 AOL published a research dataset of about 20 million search queries from more than 650,000 users over three months, with usernames replaced by numbers. Within days the numbers had been reversed. On 9 August 2006 the New York Times identified user 4417749 as Thelma Arnold, a 62-year-old widow in Lilburn, Georgia, with her consent. AOL removed the file on 7 August 2006, after copies had already spread; the chief technology officer, Maureen Govern, resigned on 21 August 2006. The pseudonymous identifier was doing its job perfectly. It was the attributes underneath it that identified people.

Arvind Narayanan and Vitaly Shmatikov submitted “How To Break Anonymity of the Netflix Prize Dataset” to arXiv on 18 October 2006 and published the mature version as “Robust De-anonymization of Large Sparse Datasets” at the IEEE Symposium on Security and Privacy in 2008. They applied their method to a dataset containing “anonymous movie ratings of 500,000 subscribers”, used the Internet Movie Database as background knowledge, and “successfully identified the Netflix records of known users, uncovering their apparent political preferences and other potentially sensitive information”. Again, no identifier was shared. The join was made on attribute patterns.

Here is the general shape, drawn once.

   System A                      System B
  +----------------+           +----------------+
  | key: p.sharma@ |           | key: p.sharma@ |
  | salary band 4  |           | clinic visits  |
  | manager: R.K.  |           | prescriptions  |
  +----------------+           +----------------+
           \                          /
            \      join on the       /
             +---> same string <----+
                        |
                        v
        +--------------------------------+
        | one row: pay + health + line   |
        | manager, held by whoever has   |
        | both files, authorized by no   |
        | one and decided by no one      |
        +--------------------------------+

The defence is the directed identifier, also called a pairwise or pairwise pseudonymous identifier: a different, unlinkable identifier for the same subject at each relying party.

NIST SP 800-63C section 6.3 sets out the requirements. The identity provider “SHALL generate a different identifier for each RP”. Pairwise pseudonymous identifiers “SHALL contain no identifying information about the subscriber” and “SHALL also be unguessable by a party having access to some information identifying the subscriber”. They “MAY be generated randomly and assigned to subscribers by the IdP or MAY be derived from other subscriber information if the derivation is done in an irreversible, unguessable manner (e.g., using a keyed hash function with a secret key)”. The same section is admirably honest about the limits: if two relying parties each hold the same name, email address and physical address alongside their different pairwise identifiers, “they could still determine that the subscriber is the same person by comparing” those attributes. Pairwise identifiers raise the cost of correlation; they do not abolish it, because Sweeney’s result still applies to whatever attributes you send.

OASIS put the same design into SAML. The SAML V2.0 Subject Identifier Attributes Profile Version 1.0, Committee Specification 01, dated 16 January 2019, defines two attributes as “a replacement for long-standing inconsistent practice” and to “address recognized deficiencies with the SAML V2.0 urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Name Identifier format”. The universal one, subject-id, must satisfy: “A given value MUST identify the same subject regardless of the context of use or the relying parties to which the Attribute is given.” The directed one, pairwise-id, is “a long-lived, non-reassignable, uni-directional identifier suitable for use as a unique external key specific to a particular relying party”, whose “value for a given subject depends upon the relying party to whom it is given, thus preventing unrelated systems from using it as a basis for correlation”. Both carry the same absolute rule: “A value MUST NOT be assigned to more than a single subject over its lifetime of use under any circumstances.” And pairwise-id adds one more: “The value MUST NOT be mappable by a relying party into a non-pairwise identifier for the subject through ordinary effort.”

The consumer-scale example arrived on 3 June 2019, when Apple announced Sign in with Apple at its Worldwide Developers Conference. Its private email relay issues an address in the privaterelay.appleid.com domain, and Apple’s developer documentation states the scoping rule exactly: relay addresses “are the same for a user across all apps written by a single development team, and different for the same user across apps written by different development teams”. That is a directed identifier shipped to hundreds of millions of phones, and it is Cameron’s fourth law implemented in a mail domain.

Two more pieces of vocabulary you will need in review meetings. NISTIR 8062, “An Introduction to Privacy Engineering and Risk Management in Federal Systems”, published January 2017, names three privacy engineering objectives, of which the relevant one is disassociability, defined in the NIST glossary as “Enabling the processing of PII or events without association to individuals or devices beyond the operational requirements of the system”. And GDPR Article 4(5) defines pseudonymisation as processing “in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately”. Note the legal consequence hiding in Article 4(1), which defines personal data as any information relating to an identifiable natural person, one “who can be identified, directly or indirectly, in particular by reference to an identifier”. Under European law, a pseudonymous identifier is still personal data. Replacing a name with a number does not take you outside the regulation.

The worked example: one email address doing all three jobs#

Now put everything on one string. Priya’s school issues her the address priya.sharma@northgate.example. Watch it play all three roles at once, and watch each role break the other two.

As an identifier. The school’s directory keys her account on the address. The namespace is the school’s user directory. The scope of uniqueness is that directory and nothing wider. The reassignment policy is whatever the school’s IT department decided, which is usually nothing written down.

As an attribute. The address is also a property of Priya: it is where you can reach her. Its value can change while she stays the same person, which is exactly what an attribute is allowed to do and exactly what an identifier is not.

As a claim. When she signs in to a third-party service using the school’s identity provider, the provider sends an assertion. Inside it sits an email claim and an email_verified claim: the provider is asserting, at a moment in time, that this address belongs to this account and that somebody checked it.

Here is what actually arrives, as the payload of an OpenID Connect ID token:

{
  "iss": "https://login.northgate.example",
  "sub": "9c81b0de4d2e4a518e772f6b1d94a0c3",
  "aud": "library-portal",
  "iat": 1754038440,
  "exp": 1754042040,
  "email": "priya.sharma@northgate.example",
  "email_verified": true,
  "name": "Priya Sharma"
}

Five of those eight fields are worth naming exactly. iss is the identifier of the issuer. sub is the identifier of the subject within that issuer. aud is the identifier of the intended recipient. iat and exp are the time bounds that turn the whole payload from a set of attributes into a dated claim. email and name are attributes carried inside the claim, not identifiers, however much they look like one.

OpenID Connect Core 1.0 says so directly, in section 5.7, “Claim Stability and Uniqueness”. It is the single most useful paragraph in the specification for our purposes:

The sub (subject) and iss (issuer) Claims from the ID Token,
used together, are the only Claims that an RP can rely upon
as a stable identifier for the End-User, since the sub Claim
MUST be locally unique and never reassigned within the
Issuer for a particular End-User. Therefore, the only
guaranteed unique identifier for a given End-User is the
combination of the iss Claim and the sub Claim.

All other Claims carry no such guarantees across different
issuers in terms of stability over time or uniqueness
across users. For instance, an Issuer MAY re-use an email
Claim Value across different End-Users at different points
in time, and the claimed email address for a given End-User
MAY change over time.

Read that against our three nouns and the whole chapter collapses into one rule. The pair iss plus sub is an identifier: a label plus its namespace, with a non-reassignment promise attached. The email value is an attribute travelling inside a claim, with no such promise. A relying party that stores email as its primary key has taken an attribute and used it as an identifier, and the specification has already told it, in advance, both ways that will fail: the same address may later belong to a different person, and the same person may later have a different address.

Now the mechanics of why email is a bad identifier even when nobody reassigns anything.

RFC 5321, the Simple Mail Transfer Protocol, sets the sizes. Section 4.5.3.1.1 states that “the maximum total length of a user name or other local-part is 64” octets, and section 4.5.3.1.2 that “the maximum total length of a domain name or number is 255 octets”. A column of VARCHAR(50) is therefore wrong before you write a line of code.

Section 2.4 of the same RFC settles case. Verbs and argument values are not case sensitive, “with the sole exception in this specification of a mailbox local-part”. It goes on: “The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user ‘smith’ is different from the user ‘Smith’. However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.”

So the standard says the left side is case sensitive, and then says please do not rely on that. Which means that an equality test on an email address is not defined by the specification. It is defined by whatever the receiving mail operator decided, and operators differ. That is a convention, not a standard, and conventions do not compare equal across organizations.

The most quoted example is Google’s, stated in its own help page: “Dots don’t matter in Gmail addresses”, and “for example, johnsmith@gmail.com and j.o.h.n.s.m.i.t.h@gmail.com are the same address and go to one inbox.” This is an implementation detail of one mail provider, not a rule of email, and it is not true of most other providers. It means that at one domain, a single mailbox has dozens of spellings, all of which will be accepted at sign-up by any service that treats the string as its key. That is one entity holding many identifiers, which is the Woolworth wallet problem stood on its head.

Put the failures in a row.

And the fix, which is three lines of policy rather than three lines of code:

1. Key every internal record on an opaque, issuer-scoped, non-reassigned identifier. iss plus sub if you are a relying party; a UUID you minted yourself if you are the issuer.
2. Store the email address as an attribute, in its own table, with the value, the time it was last confirmed, and the source that confirmed it.
3. Normalize a separate lookup column for matching, decide explicitly whether you lowercase and whether you strip dots, write the decision down as a convention rather than pretending it is a standard, and never let that column be the primary key.

Follow those three and Priya can change her surname, change her school, change her provider and hand her old address to the next Priya Sharma, and nothing in your database will quietly become about somebody else.

Kim Cameron’s Laws of Identity, twenty-one years on#

Kim Cameron, born 31 August 1948, died 30 November 2021, joined Microsoft in 1999 and worked there as chief architect of identity, and of access, until he retired in 2019. Between 2004 and 2005 he worked out a set of principles in public, argument by argument, on his Identity Weblog, with critics answering in the comments. The consolidated white paper is dated 11 May 2005. Its seven laws are the most durable piece of writing the field has produced.

The exact wording matters for three of them.

Law 2 is stated as: “The solution which discloses the least amount of identifying information and best limits its use is the most stable long term solution.” Note that Cameron argues from stability, not from ethics. Data you did not collect cannot leak, cannot be subpoenaed, cannot be mis-joined and cannot be wrong. That is the argument that eventually persuaded engineers, and it is why the derived attribute in the section above beats the raw date of birth.

Law 4 is stated as: “A universal identity system must support both ‘omni-directional’ identifiers for use by public entities and ‘unidirectional’ identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.” This is the pairwise identifier, described five years before OpenID Connect and fourteen years before Sign in with Apple, and the phrase “correlation handles” is a better name for the danger than anything the standards bodies have coined since.

Law 3 is stated as: “Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.” This is the law the industry has honoured least. It is the one that says the question is not only whether the user consented, but whether the recipient had any business being in the transaction.

That leaves the balance sheet: what the Laws got right, and what aged.

They got the nouns right. Cameron’s definition of digital identity as “a set of claims made by one digital subject about itself or another digital subject” is, structurally, the same model the W3C shipped as a Recommendation on 15 May 2025, with issuer, subject, holder and verifier made explicit. Twenty years is a long time for a definition to survive unchanged.

They got directed identity right, and completely. Pairwise identifiers went from a contested idea to a hard requirement in NIST SP 800-63C section 6.3, to a standardized SAML attribute in January 2019, to a default in a consumer sign-in button in June 2019. Very few 2005 predictions in computing have that record.

They got minimal disclosure right, and the argument from stability is why. Selective disclosure is now a shipped cryptographic feature: the Verifiable Credentials 2.0 family, recommended in May 2025, includes proof suites designed for exactly that.

What has aged is the delivery vehicle, not the principles. Cameron’s seventh law required a “unifying identity metasystem” giving users “a simple, consistent experience”, and Microsoft’s implementation of that idea was Windows CardSpace, built on the InfoCard architecture. On 15 February 2011 Microsoft posted that “based on the feedback we have received from partners and beta participants, we have decided not to ship Windows CardSpace 2.0”, pointing instead at a technology preview of U-Prove. The metasystem, as a single user-facing thing, did not happen. What happened instead was federation protocols that users never see, and the consistent experience arrived as a row of sign-in buttons rather than a card selector.

There is also a live disagreement worth stating fairly, because it is not settled as of August 2026. One camp holds that the Laws are the field’s constitution and that failures are failures of will. The other holds that Law 1’s insistence on consent has, in practice, produced consent dialogues that nobody reads, and that regulation which forbids certain data flows outright does more than any amount of user control. Both camps agree the Laws described the problem correctly. They disagree about whether user control was ever a workable lever.

A checklist you can run against a schema#

Take any table with a person in it and run these eight tests. They compress everything above.

1. Label every column as identifier, attribute, or claim about an attribute. Any column you cannot label is a bug waiting.
2. For every identifier, name the namespace, and check that it is written down next to the value rather than merely assumed.
3. For every identifier, find the operator’s published reassignment policy and read it. Do not guess it.
4. Test the primary key against the SP 800-63-4 requirement that it is “never assigned to any other entity within that context”. If it fails, it is not a primary key, it is a lookup value.
5. Find every identifier that encodes a fact. Name the fact and write down what happens the day it changes.
6. For every attribute, confirm you store the as-of time and the source. Without both, you have stored a rumour.
7. List the identifiers that also exist in a system you do not control, and write down what could be learned by joining the two.
8. Ask whether each relying party could be given a pairwise identifier instead of a universal one, and record the “necessary and justifiable” reason, in Cameron’s phrase, wherever it could not.

2.98 Common wrong ideas#

Wrong: An email address is a perfectly good primary key because everybody has one and they are unique. Right: They are not unique over time and they are not stable over a person’s life. OpenID Connect Core 1.0 section 5.7 states that an issuer “MAY re-use an email Claim Value across different End-Users at different points in time”, and that the claimed address for a user “MAY change over time”; only the iss and sub pair carries a non-reassignment promise. Key on an opaque identifier and hold the address as a dated, sourced attribute.

Wrong: A UUID is unique, full stop. Right: A version 4 UUID from RFC 9562 is unique with overwhelming probability because it is drawn from a very large random space, not because any authority checked. It also guarantees nothing about namespaces: two systems can both mint UUIDs for the same person and neither will know. Uniqueness of the value is not identity of the subject.

Wrong: Once you replace names with random numbers, the data is anonymous and outside privacy law. Right: Latanya Sweeney showed in 2000 that ZIP code, gender and date of birth alone uniquely described 87 per cent of the United States population in the 1990 Census, and GDPR Article 4(1) defines personal data to include information about a person identifiable “indirectly, in particular by reference to an identifier”. Pseudonymized data is still personal data under European law.

Wrong: Deleting a departed user’s account is the clean, privacy- respecting thing to do. Right: Deletion frees the identifier for reassignment, and every downstream record still holding it will silently attach to the next holder. Yahoo demonstrated this in 2013 when recycled IDs began receiving the previous owners’ password resets and receipts, and the industry’s answer was RFC 7293 in July 2014, which adds a timestamp so senders can say which era of the mailbox they meant. Delete the personal data; tombstone the identifier.

Wrong: A meaningful identifier is better because you can read it and sort by it. Right: It is better right up to the day the encoded fact changes, the scheme runs out of digits, or the encoded fact becomes sensitive. All three have happened at national scale: the United States retired the geography in Social Security Numbers on 25 June 2011, and the book trade had to move every system to thirteen-digit ISBNs by 1 January 2007 because ten digits had run out. Use an opaque value with a check digit and put the meaning in its own column.

Wrong: Attributes and claims are the same thing with different jargon. Right: An attribute is a property of a subject; a claim is somebody’s assertion that the property holds. The W3C Verifiable Credentials Data Model 2.0, a Recommendation since 15 May 2025, defines a claim as “an assertion made about a subject” and requires an issuer to carry it. Systems never see attributes directly; they only ever see claims, and a claim with the asserter and the date stripped off cannot be evaluated at all.

Wrong: Pairwise identifiers make users untrackable. Right: They remove one join key and no more. NIST SP 800-63C section 6.3 states that colluding relying parties “could still determine that the subscriber is the same person by comparing the name, email address, physical address, or other identifying attributes” sent alongside. Pairwise identifiers must be paired with minimizing the attributes you release, which is Cameron’s second law.

Wrong: Uniqueness is a single yes-or-no property of an identifier. Right: It is at least three separate promises: unique among current rows, unique across the whole history of the list, and meaningful outside the list. A school roll number keeps the first only; an ORCID iD keeps all three; a telephone number keeps the first and the third but not the second. Most bugs are somebody assuming a promise the issuer never made.

Wrong: The namespace is obvious from context, so there is no need to store it. Right: Context is exactly what is lost when data moves between systems, which is when it matters. SP 800-63-4 builds the namespace into the definition itself, requiring an identifier to be associated with a single entity “within a given context”, and RFC 9562 ships four predefined namespace UUIDs so that the same name hashed under DNS and under URL produces two different identifiers, on purpose.

Wrong: Kim Cameron’s Laws of Identity are a historical curiosity from the CardSpace era. Right: CardSpace was cancelled on 15 February 2011, but the fourth law, directed identity, is now a hard requirement in NIST SP 800-63C, a standardized attribute in the OASIS SAML Subject Identifier Attributes Profile of 16 January 2019, and the default behaviour of Sign in with Apple, whose relay addresses Apple documents as “different for the same user across apps written by different development teams”. The product died; the principles shipped.

2.99 Chapter summary in 20 lines#

1. Three different objects are all called identity, and confusing them causes more identity bugs than any cryptographic weakness.
2. An identifier is a label that points at exactly one entity inside one namespace, and it carries a promise about never being reused.
3. NIST SP 800-63-4, published 1 August 2025, defines an identifier as associated with a single unique entity within a given context and never assigned to any other entity within that context.
4. An identifier written without its namespace is not weak information; it is incomplete information, like a number without units.
5. Uniqueness is three separate promises: unique now, unique across all time, and meaningful outside the issuing list.
6. An attribute is a property of the subject, and it is only ever true at a particular time, according to a particular source.
7. A correctly stored attribute has four parts: name, value, as-of time and source, and the last three are the ones schemas drop.
8. A claim is an assertion by a named party that an attribute holds, and the W3C Verifiable Credentials Data Model 2.0, a Recommendation since 15 May 2025, defines it as an assertion made about a subject.
9. Systems never handle attributes directly; they handle claims about attributes, and stripping the asserter destroys the ability to judge.
10. Identifiers move through assignment, suspension, retirement, quarantine and reassignment, and reassignment is the transition that causes incidents.
11. Tombstoning, meaning retiring a label and never reissuing it, costs namespace and buys correctness, and is usually the right trade.
12. In 2013 Yahoo recycled user IDs inactive for twelve months and new owners received the old owners’ password resets and receipts.
13. RFC 7293 of July 2014 answered that by adding a Require-Recipient-Valid-Since header so senders can say which era of a mailbox they meant.
14. Meaningful identifiers rot in three ways: the encoded fact changes, the scheme runs out of digits, or the encoded fact turns sensitive.
15. The United States removed geography from Social Security Numbers by randomization on 25 June 2011, and the book trade moved to thirteen-digit ISBNs on 1 January 2007 for want of capacity.
16. When one identifier appears in two systems it becomes a join key, and the two files stop being separate without anybody deciding so.
17. Latanya Sweeney showed in 2000 that ZIP code, gender and date of birth uniquely described 87 per cent of the United States population, so attributes correlate even without identifiers.
18. The defence is the directed or pairwise identifier, required by NIST SP 800-63C section 6.3 and shipped at consumer scale by Sign in with Apple from June 2019.
19. An email address is an identifier, an attribute and a claim at once, and OpenID Connect Core 1.0 section 5.7 warns that only the issuer and subject pair may be relied on as stable.
20. Kim Cameron’s seven Laws of Identity, dated 11 May 2005, described all of this before the protocols existed, and the fourth law, directed identity, is now the industry default.

Chapter sources: Kim Cameron, “The Laws of Identity”, white paper dated 11 May 2005, published on the Identity Weblog, for the seven laws and for the definitions of digital identity and claim; the Microsoft Identity blog post “Beyond Windows CardSpace” of 15 February 2011 for the cancellation of Windows CardSpace 2.0. W3C Verifiable Credentials Data Model v2.0, W3C Recommendation of 15 May 2025, sections 4.4 Identifiers and 4.9 Validity Period and the Terminology section, for claim, credential, issuer, holder, subject, verifier, entity, the id property, and the note that identifiers of any kind increase correlatability. NIST Special Publication 800-63-4, Digital Identity Guidelines, published 1 August 2025 and superseding SP 800-63-3 of June 2017 with errata of 1 December 2017 and 2 March 2020, glossary entries for identifier, attribute, attribute value and digital identity; NIST SP 800-63C section 6.3 for pairwise pseudonymous identifiers; NISTIR 8062, “An Introduction to Privacy Engineering and Risk Management in Federal Systems”, January 2017, and the NIST CSRC glossary, for disassociability. OpenID Connect Core 1.0 incorporating errata set 2, section 5.7 “Claim Stability and Uniqueness”, for sub, iss and the reuse of email claim values. OASIS SAML V2.0 Subject Identifier Attributes Profile Version 1.0, Committee Specification 01, 16 January 2019, for subject-id and pairwise-id. RFC 9562, “Universally Unique IDentifiers (UUIDs)”, May 2024, obsoleting RFC 4122, for UUID versions 4 and 7 and the four predefined namespace IDs; RFC 5321, Simple Mail Transfer Protocol, sections 2.4, 4.5.3.1.1 and 4.5.3.1.2, for local-part case sensitivity and the 64-octet and 255-octet limits; RFC 7293, “The Require-Recipient-Valid-Since Header Field and SMTP Service Extension”, July 2014; RFC 2606, June 1999, for reserved example domains. ITU-T Recommendation E.164, “The international public telecommunication numbering plan”, current version approved 13 February 2026, fifteen-digit maximum since the 1997 revision. ISO/IEC 24760-1:2019 second edition with Amendment 1:2023, now withdrawn, and its replacement ISO/IEC 24760-1:2025 third edition of September 2025, checked on the ISO catalogue in August 2026; and ISO 2108:2005 with the ISO news item of October 2006 on the 1 January 2007 move to thirteen-digit ISBNs. Regulation (EU) 2016/679, the General Data Protection Regulation, Articles 4(1), 4(5) and 5(1)(d). Social Security Administration history pages on the most misused SSN, 078-05-1120, the E. H. Ferree company of Lockport, New York, and Hilda Schrader Whitcher, and the SSA employer page on SSN randomization from 25 June 2011. Unique Identification Authority of India, About UIDAI, for the twelve-digit random Aadhaar number and the figure of 142.76 crore numbers generated as on 16 September 2025, and the launch at Tembhli, Nandurbar district, Maharashtra, on 29 September 2010. Latanya Sweeney, “Simple Demographics Often Identify People Uniquely”, 2000, using 1990 US Census summary data. Arvind Narayanan and Vitaly Shmatikov, “How To Break Anonymity of the Netflix Prize Dataset”, arXiv cs/0610105 submitted 18 October 2006, published as “Robust De-anonymization of Large Sparse Datasets”, IEEE Symposium on Security and Privacy, 2008. Contemporary reporting on the AOL search log release of 4 August 2006, the New York Times identification of user 4417749 on 9 August 2006, and the resignation of AOL’s chief technology officer on 21 August 2006; contemporary reporting on Yahoo’s user ID recycling programme of June to September 2013. LiveLaw report of 3 November 2023 on Writ Petition (Civil) No. 699 of 2021, Rajeswari v Union of India, Supreme Court of India, for TRAI’s ninety-day rule on reallocating deactivated mobile numbers. Amazon Web Services S3 User Guide, general purpose bucket naming rules, as of August 2026. Apple Developer documentation, “Communicating using the private email relay service”, and the announcement of Sign in with Apple at WWDC on 3 June 2019. Google Gmail Help, “Dots don’t matter in Gmail addresses”. ORCID support documentation, “Structure of the ORCID Identifier”, for the sixteen-digit format and the ISO/IEC 7064:2003 MOD 11-2 check digit.