Shared by every event
Each DADE event is a Security Event Token (SET, RFC 8417) carried over the Shared Signals Framework. The event types live under https://schemas.openid.net/secevent/dade/event-type/, and every one of them can carry these common claims in addition to its own.
| Claim | Req | Meaning |
|---|---|---|
| governing_law | Recommended | The law against which this event's consequence is to be evaluated: jurisdiction (ISO 3166-2 or -1 alpha-2) and as_at (a date). as_at is not redundant with the timestamp, for two reasons: an amendment can take effect retroactively, so the law as at a past date is not fixed merely because the date has passed; and a jurisdiction can hold two rules in force at once and select between them by the instrument's age rather than the event's, in which case reading its law “as of today” gives the wrong test for part of the population. |
| initiating_authority | Recommended | Who declared the transition. The weight a Receiver gives an event depends substantially on this.court registrar notary clinician agency principal custodian claimant operation-of-law |
| canonical_role | Optional | The role held or claimed, from a cross-jurisdiction vocabulary, so that an executor, a liquidator and a Nachlassverwalter line up as one role. |
| evidence | Optional | Supporting evidence, using the evidence structures of OpenID Connect for Identity Assurance. Its document, electronic_record and vouch types already cover a death certificate, a register entry and a third party attesting to standing. |
| effect_unspecified | Optional | The Transmitter asserts the fact and expressly declines to characterise its legal effect. A Receiver MUST NOT infer a consequence the Transmitter has declined to assert. |
| event_timestamp | Optional | When the transition took effect in law, as distinct from when it was recorded. A death registered three days late carries the earlier time. |
| supersedes / corrects | Optional | The jti of an earlier SET this one replaces, or corrects and withdraws. A Receiver that acted on a corrected event SHOULD unwind that action so far as it is able. |
| reason_admin / reason_user | Optional | Localized messages keyed by BCP 47 language tag. reason_user is usually omitted here — the subject is dead. |
Subjects
RFC 9493 defines no Subject Identifier Format for a person who has died, and the formats it does define fit badly: an email or phone_number identifier for a decedent is both likely to be reassigned and unusually sensitive. Draft 00 adds a principal format with an opaque principal_ref, scoped per Transmitter–Receiver pair, and an optional jurisdiction.
The subject of every event is the principal — the person whose death, capacity or affairs it concerns — so a Receiver can correlate the whole sequence on sub_id alone. A holder travels in the event body, not as the subject.
Facts, not effects
A court appoints a conservator over the property of someone who had granted a power of attorney. Across seven US states that one event has five different effects on the existing power: it continues; it terminates; the court allocates functions between the two; the conservator acquires the principal's own power to revoke it; or the power is suspended and later reinstated if capacity returns.
An event asserting "the power of attorney is terminated" is therefore wrong in five of the seven. One asserting "a conservator was appointed, under the law of Iowa, as at this date" is right in all of them.
A second case explains the date. Colorado runs two durability tests at once, selected by the age of the instrument: the current default for a power created after 1 January 2010, and a superseded magic-words section — still in force — for one created before it. Knowing the jurisdiction is not enough; a Receiver has to know as of when.
authority_status: reinstated
capacity_status: restored
record_status: withdrawn