الساعة
كل تاريخ في هذه الصفحة حدّده برلمان، لا نحن.
هذه ليست خارطة طريق. إنها قائمة صكوك قانونية مقترنة بتواريخ، وأولها قد مضى بالفعل. ولا شيء أدناه مكتوب ثم متروك ليبلى: كل عدٍّ تنازلي يُحسب من ساعتك أنت عند تحميل الصفحة، حتى يبقى موعدٌ يبعد ستة أسابيع بعيدًا ستة أسابيع لمن يفتح هذه الصفحة بعد عام.
RECORDED Next deadline
6 days from now
UK digital verification services (DVS) trust framework v1.0 — no earlier than 1 September 2026
reading your clock…
RECORDED Already in force
4
of 11 legal instruments on this page
counting against your clock…
RECORDED Still to come
7
none of which move because anyone is busy
counting against your clock…
The instruments, in the order they bite
Sorted by urgency rather than by region: what already binds you comes first, and after that the nearest date leads. Every row carries the instrument, who it binds, and its citation. A row without a citation would be an opinion with a date on it, so there are none.
eIDAS 2.0 — very large online platforms —
in force for 2 years · European Union
Very large online platforms must accept the wallet where users are required to authenticate for access to an online service.
Who this binds: Designated very large online platforms.
How this date is arrived at: Art 5f(3) states no application date of its own, and Regulation (EU) 2024/1183 defers none in Art 2 — so on its face this has applied since the Regulation entered into force on 20 May 2024. That reading is ours, and the Article is cited so you can check it rather than take it.
Note: Gatekeepers are a different matter and are widely misreported — there is NO gatekeeper acceptance duty anywhere in the amended eIDAS. See the note below the register.
Regulation (EU) 2024/1183, Art 5f(3) · checked 2026-08-19
European Accessibility Act —
in force for 14 months · European Union
An enumerated, closed list of products and services sold to consumers in the EU must meet the Act's accessibility requirements.
Who this binds: Economic operators dealing in the listed products and services — and only through 27 national transposing laws, which differ in scope, enforcement and penalty. It is a Directive: it never applies to anybody directly.
Note: Four qualifiers that are usually dropped. Microenterprises providing services are exempt (Art 4(5)); there is a disproportionate-burden defence (Art 14); transitional regimes run to 28 June 2030, with existing service contracts and a 20-year allowance for self-service terminals (Art 32); and Art 2(4) carves out some content. "The Accessibility Act applies to private businesses" is not a true sentence.
Directive (EU) 2019/882 — Arts 2(4), 4(5), 14, 32 · checked 2026-08-19
EU Anti-Money Laundering Authority —
in force for 14 months · European Union
The AMLA Regulation has applied since this date.
Who this binds: The Authority itself, and the framework around it.
Note: Its direct supervision of selected obliged entities does not begin until 2028. This one is routinely listed as a 2027 date; it is not.
Regulation (EU) 2024/1620, Art 108 · checked 2026-08-19
Australia AML/CTF Amendment Act 2024 —
Commenced 31 March 2026; obligations apply 1 July 2026. Two different dates, and the countdown runs to the second one, because that is the one you are planning against.
in force for 2 months · Australia
Schedule 3 — which IS tranche 2 — commenced on 31 March 2026, and that is also when existing reporting entities' new obligations began. But programs, customer due diligence, reporting and record-keeping were disapplied until 1 July 2026, so that is when obligations actually bit for the newly regulated cohorts: tranche 2 and new virtual asset services alike.
Who this binds: Real estate, precious metals and stones, and professional services under tranche 2; and virtual asset services. Only pre-existing digital currency exchanges were genuinely caught in March — the Transitional Rules deferred the same obligations, and the travel rule, to 1 July 2026 for every other virtual asset service.
What we could not check: AUSTRAC's own guidance site was unreachable when this row was checked, so we cannot tell you whether any administrative forbearance or supervisory-priorities statement has been published since 1 July 2026. The row rests on the two controlling primary instruments, which outrank guidance in any case — but we are not going to imply an enforcement posture we have not read.
Anti-Money Laundering and Counter-Terrorism Financing Amendment Act 2024 (Cth), No. 110 of 2024, Sch. 3 incl. Pt 4 item 11; Transitional Rules F2026L00393, s.12 · checked 2026-08-19
UK digital verification services (DVS) trust framework v1.0 —
6 days from now · United Kingdom
Version 1.0 comes into force on the date the first conformity assessment body is accredited to certify against it.
Who this binds: Providers seeking certification against v1.0. Existing gamma (0.4) certified providers get at least 15 months to uplift, on a bespoke per-service cycle.
This date is conditional. This date depends on a UKAS accreditation event. gov.uk states it will be no earlier than 1 September 2026 — a floor, not a date. Whether the first conformity assessment body has since been accredited is NOT something we have confirmed, which is why this row says "no earlier than" and never "from".
Note: Two things this material commonly gets wrong, both of which the first draft of this page got wrong too. The framework was RENAMED in March 2026 — "Digital Identity and Attributes", DIATF, is retired. And the 31 March 2026 date usually attached to v1.0 belongs to a different version entirely: that is when beta (0.3) certificates expired and services had to be on gamma (0.4).
DVS trust framework v1.0, finalised 9 June 2026; Data (Use and Access) Act 2025 · checked 2026-08-19
eIDAS 2.0 — the wallet obligation —
4 months from now · European Union
Each member state must provide at least one European Digital Identity Wallet to all natural and legal persons in the Union.
Who this binds: Member states, and only member states. No obligation whatsoever falls on a private vendor here, including on us. A state without a wallet is in breach; a company without one is not.
How this date is arrived at: Not a date the legislator prints anywhere. The implementing acts were published in the Official Journal on 4 December 2024 and entered into force on the twentieth day, 24 December 2024; Art 5a(1) allows 24 months. 24 December 2024 + 24 months = 24 December 2026. The Commission's own European Digital Identity page states no date at all.
Note: The big one. Note the Article's own words: at least one wallet, for all natural and legal persons. Legal persons are in scope, and the popular paraphrase about citizens and residents is both narrower and not what the text says.
Regulation (EU) 2024/1183, Art 5a(1) · checked 2026-08-19
CCPA/CPRA — automated decision-making technology —
4 months from now · California, United States
Full compliance with the ADMT rules is required.
Who this binds: Businesses subject to the CCPA that use ADMT for significant decisions about a person.
Note: Two qualifiers that both cut AGAINST urgency, which is exactly why they are here. The risk-assessment duty that began on 1 January 2026 applies to newly initiated processing (§ 7155(a)(1)); processing already underway before that date has until 31 December 2027 (§ 7155(b)), which for most businesses is the operative deadline. And the 1 April 2028 event (§ 7157) is an attestation under penalty of perjury plus summary metadata, signed by a member of the executive management team — not submission of the assessment itself, which goes to the Agency only on request, within 30 days.
California Consumer Privacy Act as amended by the CPRA; CPPA regulations §§ 7155, 7157 · checked 2026-08-19
UK Money Laundering and Terrorist Financing (Amendment) Regulations 2026 —
Commenced 30 June 2026; obligations apply 1 February 2027. Two different dates, and the countdown runs to the second one, because that is the one you are planning against.
5 months from now · United Kingdom
Commencement is staged. The general body was made on 9 June 2026 and came into force 21 days later, on 30 June 2026. Regs 20 and 36(b) — including the new reg. 34A enhanced due diligence for cryptoasset exchange and custodian wallet providers — apply from 1 February 2027, and reg. 37 for remaining purposes from 25 October 2027.
Who this binds: UK firms regulated under the Money Laundering Regulations 2017.
Note: The cryptoasset provisions most firms are actually asking about land on 1 February 2027, not on the June 2026 in-force date. A rebutter will not attack the date on this row; they will attack the name, so it carries the SI number.
SI 2026/621 — regs 20, 34A, 36(b), 37 · checked 2026-08-19
Swiss e-ID (swiyu) — trust infrastructure —
10 months from now · Switzerland
This is a programme schedule, not a legal deadline. It can move, and it has.
The trust infrastructure is expected to be operational, which the office states holds regardless of when the e-ID itself is introduced.
Who this binds: Nobody. This is the Swiss Confederation's own schedule for its own programme.
Note: There is currently no announced launch date for the Swiss e-ID at all. The 1 December 2026 date was abandoned on 30 June 2026 — see the section below.
Federal Office of Justice, revised timetable for the e-ID and the trust infrastructure, 30 June 2026 · checked 2026-08-19
AMLD6 — the anti-money-laundering Directive —
10 months from now · European Union
Member states must transpose the Directive into national law across four staggered dates. Two of them have already elapsed.
Who this binds: Member states, which then bind firms through national law. This one IS a Directive and DOES require transposition — it is routinely, and wrongly, described as directly applicable alongside the Regulation.
How this date is arrived at: The countdown runs to 10 July 2027, the next tranche after today. The 2025 and 2026 tranches have passed; the last is 2029.
Directive (EU) 2024/1640 · checked 2026-08-19
EU AML Regulation —
10 months from now · European Union
The Regulation applies directly across the Union, with no national transposition step in between.
Who this binds: Obliged entities across the EU.
Note: Football agents and clubs are deferred to 10 July 2029 under the same Article.
Regulation (EU) 2024/1624, Art 90 · checked 2026-08-19
eIDAS 2.0 — the private-sector acceptance obligation —
16 months from now · European Union
Private relying parties that are already required — by Union or national law, or by contract — to use strong user authentication must accept the wallet, and only when the user asks them to.
Who this binds: Those relying parties, with microenterprises AND small enterprises excluded. Banking, telecom and healthcare appear in the text as examples, not as the operative trigger: a firm under no strong-authentication requirement is outside this Article whatever sector it trades in.
How this date is arrived at: Same trigger as the wallet obligation, a different offset: 24 December 2024 + 36 months = 24 December 2027. It falls a full year after the wallet date, and the two are frequently collapsed into a single range.
Note: The commercially significant one: it creates demand-side duty rather than supply-side duty.
Regulation (EU) 2024/1183, Art 5f(2) · checked 2026-08-19
Switzerland, and what it actually tells you
On 25 February 2026 the Swiss Federal Department of Justice and Police published a statement on its national e-ID programme, under the heading of strengthening acceptance of the e-ID. One section of it reads:
For cost-saving reasons, however, all planned further developments must currently be abandoned, in particular the connection to international e-ID systems, the federal government's back-up service, and the issuance of e-IDs in third-party wallets.
The named cause was a parliamentary budget cut of CHF 1.7 million for 2026. That same statement still expected the e-ID to go live on 1 December 2026.
Then the date went too. On 30 June 2026 the same office abandoned the 1 December launch, and Switzerland currently has no announced e-ID launch date at all. Only the trust infrastructure carries an expectation — the first half of 2027 — and the office says that holds regardless of when the e-ID itself arrives. The reason given for the second slip was not money: it was the risk that AI-generated forgeries pose to the online issuance process.
Four things this is not, because the story is worthless told
loosely. It is not news — the first decision is six months old. It is
not the withdrawal of a shipped capability: issuing into third-party wallets was
never live, no e-ID has been issued to anybody, and the wording is must currently be
abandoned
, which defers planned work. It is not a repeal — the Act was
upheld at referendum and survived a Federal Supreme Court challenge dismissed on 21 April
2026, though it has not yet been brought into force. And it is not only about
wallets — it also stopped the connection to international e-ID systems and the federal
government's own back-up service, which are the larger two of the three.
Sources: Federal Department of Justice and Police / Federal Office of
Justice, eid.admin.ch — Strengthening acceptance of e-ID with additional
measures
, 25 February 2026, contact Rolf Rauschenbach, Federal Office of Justice; and
the revised timetable for the e-ID and the trust infrastructure, 30 June 2026. Checked
2026-08-19.
What “certified” currently means in this field
The OpenID Foundation opened self-certification for OpenID4VP 1.0 and OpenID4VCI 1.0 with HAIP on 7 August 2026. Checked on 2026-08-19, the two registers carry three organisations between them holding eighteen certifications: a protocol-testing harness with fourteen, one funded identity vendor with three, and an open-source project with one. No established vendor appears. We are not on it either.
We are telling you when it opened and who is on it rather than telling you what to conclude — and the caveat runs against us as much as against anyone: a register opened on 7 August 2026 is far too young for the absence of the large vendors to mean anything yet. A reader comparing suppliers deserves both halves of that, including the half that is inconvenient for whoever would like to sell them something.
To a government reading this
An offer, not a pitch. Everything here runs on open protocols, under your own domain, with your own signing key. If you leave, you leave with your credential types, your issuer identity, and your holders' credentials still verifying — because verification resolves your domain, not ours. Departure costs one DNS record. We think that is the only honest way to sell infrastructure to a state: make leaving cheap, and then earn the renewal every year.
To the people building the same thing
If you are a competitor reading this, the interoperability point is
sincere and it is not a courtesy. We implement OpenID4VCI and OpenID4VP, SD-JWT VC and
did:web — the same open standards you do, none of which we invented and
none of which we control. A credential is only worth holding if more than one party will
accept it, which means every issuer who joins makes every holder's wallet more useful,
including issuers who will never be our customers. A rival who implements OpenID4VCI
correctly is a good outcome for the person holding the credential — and the person
holding the credential is the only party whose interests we have agreed to put first. We
would rather lose a tender to a conformant implementation than win one with a proprietary
format that traps the holder.
To the person these deadlines are actually about
Every instrument on this page exists because somebody decided you must be able to prove a thing about yourself without handing over the record of having proved it. That is what you get from it: you show the one fact that was asked for, the party checking learns nothing else, and no register of where you proved it accumulates anywhere — including here. That is not a product being sold to you. It is a thing the law now says you are owed.
Why this is our position and not our marketing
The friendliness of this page is not a posture adopted for a launch. It is written into the document this company was founded on, published in full and scored against what actually runs at /declaration — including the six Articles this system does not honour yet.
Open protocols, standards, and technologies shall form the backbone of our shared digital world, developed through inclusive multi-stakeholder processes rather than corporate fiat.
Article VIII — Digital Commons and Infrastructure Justice
Technical standards, platform policies, and digital regulations must be developed through inclusive, transparent processes that center the needs of affected communities, especially those historically marginalized.
Article X — Collective Digital Self-Governance
How to check this page rather than trust it
Every date above was read against its own source on 2026-08-19, and each row prints the citation it was read from. The countdowns are computed in your browser from your device clock — if your clock is wrong, this page is wrong in exactly the same direction, which is the honest failure mode. Change your device date and reload: every number here moves, because none of them was written down.
The claims this page makes about this system, as opposed to about the law, are checkable at /capabilities and /standards, and the cell serving this page identifies its own build at /build.
Ask this site
Try:
- IssuerSigns a claim about you. Learns nothing afterwards.
- Holder — youKeeps it. Chooses what to show, and to whom.
- VerifierChecks the signature and the status. Does not call the issuer.
The arrow that is missing is the one that matters: there is none from the verifier back to the issuer, which is why the issuer cannot see where you went.
- Read the token and the key it names.
- Resolve the issuer’s key document.
- Recompute that key’s thumbprint and compare it to the name in the token.
- Verify the signature, using the algorithm the token itself declares.
Every step is arithmetic the receiving party performs. None of it asks the issuer to vouch for the issuer.
ExampleA credential with four claims, of which two are sent:
| Claim | Value | Sent? |
|---|---|---|
| given_name | Ada | sent |
| date_of_birth | 1970-01-01 | withheld |
| over_18 | true | sent |
| address | … | withheld |
The issuer’s signature still verifies over the two that were sent, because the two that were not are committed to as salted digests rather than as values.
Everything this search can see — all 27 pages, and what each one claims
- ORBIS.IDYour identity belongs to you. Right now, it belongs to everyone else.Every time you sign up for something, you hand over a copy of yourself — a photo of your passport, a scan of your face, your date of birth. Those copies pile upSections: The grievance, the Article, and the proof · The problem, in one sentence you already know · Five promises — and what each one actually means · Three people, one seal, no copies · The screen where you decide · What we can see, and what we cannot
- Declaration of Digital IndependenceUniversal Declaration of Digital Independence and Human Digital RightsThe founding document of this estate, written by Jonatan Schmidt and published here unedited. Next to each Article is what the running system actually does abouSections: Universal Grievances Against Digital Oppression · Universal Principles of Digital Sovereignty · A Universal Call to Unified Action · In Witness Whereof · The honest case against this whole idea
- The Trust FabricTrust, woven in.The trust fabric for the real economy — it turns everyday life into proof you own . An issuer signs a statement, a holder keeps it and decides who sees it, and Sections: Split trust into three roles — never merge them. · A bill becomes proof. Proof becomes credit. · Honesty is the architecture. · The fabric cannot be retrofitted. · Three converging markets — one regulatory clock. · The lines the product already says for itself.
- Demo consoleThe only demo here is the real thing.There is no recorded walkthrough on this page, no simulated data and no screenshot of a product. There is a running trust plane and the commands that talk to itSections: 01 · The trust anchor · 02 · What this issuer issues · 03 · Is it healthy right now · 04 · Revocation, signed · 05 · Prove it against the published conformance vectors · Two lists, same page, same weight
- DocumentationGenerated from the route table, so it cannot drift.The wire contract is derived from the live routing table on every request. The document and the server cannot disagree, because one is made out of the other.Sections: Start here · The full contract
- DevelopersEverything below is a live response.Not documentation of an intended one. Five commands, no account, no API key, no sales call. Run them before you decide whether to keep reading.Sections: 01 · The trust anchor · 02 · Issuer metadata · 03 · The credential shape · 04 · Conformance vectors — check your implementation, not ours · 05 · Revocation, signed · Readiness that reports the hardware
- CapabilitiesEvery claim, its real state, and the proof.25 entries: 14 live · 1 partial · 1 planned · 9 not yet. Each one was checked against the cell serving this page. Almost nobody in this industry publishes the rSections: What the four words mean · Identity · Issuance · Operations · Verification · Standards
- StandardsOne row per standard. Including the ones we fail.5 live · 4 partial · 0 planned · 3 not yet. Every row states what the standard demands , what this cell actually does, and the artefact that settles it. Two rowSections: What the four words mean · Credential formats, as their own register · Why every row carries a state
- RegulationsThe posture, in the same discipline.Conformant where it is true, planned where it is not yet, and never silent about the difference. Data minimisation here is a property of the credential format, Sections: Data minimisation, enforced by cryptography · What the four words mean · Compliance and security capabilities · Security · Compliance · Certification status, stated once and plainly
- For peopleThe answer is smaller than the question.You photographed your passport again this month. Someone needed to know one thing about you. They now hold your name, your face, your address and your date of bSections: Prove the fact. Keep everything else. · What changes for you · What is real today, and what is not · If you are here for someone else
- For businessYour own issuer. Your own domain.You mint your own credential types under your own domain. Your members hold them. Your counterparties check them offline, against a public key, with nothing to Sections: You are not early. The deadlines already exist. · The live example is not a mock · What a buyer actually asks · Two lists, same page, same weight · Getting started
- For citiesA city is a tenant, with its own key.Resident credentials a city issues under its own did:web , checked by services across the city with no shared resident database in the middle — because the checSections: Why the architecture is not city-specific · What a city actually gets from this · Two lists, same page, same weight
- For governmentTwo questions, both answered with endpoints.What does it conform to, and what is provable without taking our word for it. Everything below links the artefact that settles it — a document you fetch, a fileSections: The property that comes before everything else · Conformance, one row per standard · Accountability · Two lists, same page, same weight
- PartnersFour roles, and what each one runs.Issuer partners mint their own types under their own tenant. Relying parties verify against the trust anchor. Wallet partners hold on a person's behalf. Data paSections: A page each, with its own evidence · How intake works, and what it costs you · Two lists, same page, same weight
- Apply as a partnerApply, and here is exactly what happens next.The intake is a public, rate-limited endpoint you can call right now. What happens after it is a person, not a pipeline, and this page says which steps are whicSections: Step 1 · Call the intake · Do it here · What each step actually is · What we do with what you send
- Application statusWhere your application is, without asking us.A public endpoint answers with the state of an application you hold the id for. No account, no sign-in, no email thread.Sections: Ask it directly · Check it here · What the states mean
- Issuer partnersYour own key, your own domain, your own exit.An issuer partner runs a tenant with its own did:web , its own signing key, its own status list and its own credential types. The credentials you mint are verifSections: What you actually get, and you can look at all of it now · The formats, as a register · The exit, stated before you sign anything · Two lists, same page, same weight
- Relying-party partnersVerification takes no key. Count the routes.There is nothing to buy and nothing to sign up for on the verifying side. The verification plane takes no authentication at all, and that is a structural properSections: Count it yourself · What you integrate: three fetches · Test your verifier against ours, offline · What is not proved yet, on the record
- Wallet partnersWhat a wallet has to speak to interoperate.The protocols, the format, and the key custody we expect. And the thing no other page in this industry will tell you: nothing has ever completed this flow againSections: The discovery surface, live now · What we expect of you, and what you can expect of us · Aligned with HAIP 1.0
- Data partnersA signed contract, an audit chain, and a short list.A data partner exchanges verified attributes under a signed agreement, with every exchange recorded in a tamper-evident chain. It is also the least built of theSections: What is real underneath · Compliance · What a data partner would get and give · If you want to be first
- Verify with ORBISThe plane designed to survive everything else being down.Verification needs no signing key, no issuer identity and no vault — a cell can be configured for verification alone. It also needs no permission: 107 of this cSections: Three fetches, no account · The honest line between implemented and witnessed · Two lists, same page, same weight
- The clock — the deadlines, counted liveEvery date on this page was set by a parliament, not by us.This is not a roadmap. It is a list of legal instruments with dates attached, and the first one has already gone. Nothing below is written down and left to rot:Sections: The instruments, in the order they bite · Switzerland, and what it actually tells you · What “certified” currently means in this field · To a government reading this · To the people building the same thing · To the person these deadlines are actually about
- How ORBIS compares — and where it loses6 axes. 2 no established vendor holds. 3 we do not hold ourselves.Dozens of vendors sell pieces of this. The founding brief compared fourteen of them across six capabilities and concluded that no competitor held more than threSections: The matrix · Every axis, and how to check it · The discovery probe · What can be proved right now · What we withdrew · The honest gaps
- Your accountAn account with no password to steal.Not a row in our database with your email on it. An ORBIS.ID account is a key , and the half that matters is designed to be born on your own device and never seSections: What an account actually is · How you get one · What the account can do · How to leave with everything · If you are not here as a person
- For your organizationYour own issuer identity — and your own way out.An organization on ORBIS is not an account on our platform. It is a tenant with its own web identity, its own signing key, its own revocation list and its own cSections: What your organization becomes · What onboarding actually involves · What it does not require · Three pages, one for each question · The other two doors
- The operator back officeThe operator console, and the door that will not open yet.Issuance, revocation, the trust registry, the approvals plane, the audit chain and the compliance desk — 195 operator-authenticated operations , the largest surSections: What the back office does · The door, and why it is shut · How an operator signs in · Count it yourself · The other two doors
- Network operations centreEvery panel on this page is a reading your own browser just took.The trust chain resolved live, the revocation field decoded from the signed list, the audit hash chain recomputed link by link, and this cell’s latency measuredSections: The chain that draws itself as it proves itself. · Tamper-evident, and you are welcome to try. · The finding this page would rather report than hide. · What an operator commands, counted from the wire. · Stated here rather than found later.
The words, in plain language — 11 terms, each naming the specification it glosses
- Verifiable credential
- Also searched as: verifiable credential, vc, credential, digital credential, what is a credential, certificate
- A set of claims about someone, signed by whoever issued them. The signature is what makes it verifiable: whoever receives it can prove it has not been altered and can name the key that signed it, without calling the issuer to ask. It is not a login and not a row in somebody’s database — it is a document the subject holds and presents.
- Gloss of W3C Verifiable Credentials Data Model 2.0. The concrete format on this cell is SD-JWT VC (IETF). This site’s own claim: /capabilities · served by this cell: /manifest
- Issuer, holder, verifier
- Also searched as: issuer, holder, verifier, roles, who is the issuer, difference between issuer and verifier, three roles, relying party
- Three roles, separated on purpose. The ISSUER signs a claim about you. The HOLDER — you — keeps it and decides who sees it. The VERIFIER checks the signature and the status. Because the verifier does not have to call the issuer to do that check, the issuer does not learn where you used the credential. That separation is the entire point of the model; collapse it and you have rebuilt a login provider.
- Gloss of W3C Verifiable Credentials Data Model 2.0, which defines these three roles. This site’s own claim: /trust-fabric
- The trust chain
- Also searched as: trust chain, how do i know, real, genuine, authentic, fake, forged, tampered, how is it verified, verification, verify, verified, signature, signed, trust anchor, check, checked, proof, prove
- Checking a credential is four steps, in order, and every one of them can be done by the party receiving it. Read the token and the key it names. Resolve the issuer’s key document. Recompute that key’s thumbprint and compare it to the name in the token. Verify the signature with the algorithm the token itself declares. Nothing in that sequence requires trusting the issuer’s word about the issuer.
- Gloss of RFC 7638 (JWK thumbprint), RFC 7515 (JWS), W3C DID Core for resolving the key. This site’s own claim: /trust-fabric · served by this cell: /.well-known/did.json · /conformance/vectors
- Selective disclosure
- Also searched as: selective disclosure, sd-jwt, sd jwt, withhold, hide claims, privacy, share less, minimum disclosure, only show my age, zero knowledge
- Handing over some claims and withholding others without invalidating the issuer’s signature. Each claim is committed to in the signed payload as a salted hash rather than as the value itself; you send only the disclosures you choose, and the receiver recomputes the digests of what you actually sent. Withholding a claim is therefore not an act of trust or of policy — the arithmetic simply does not contain it.
- Gloss of IETF SD-JWT and SD-JWT VC. This site’s own claim: /regulations
- Revocation and status
- Also searched as: revocation, revoked, status list, expired, cancel a credential, withdraw, still valid, status
- A credential can be withdrawn after it is issued, so a verifier needs a way to ask whether this one still stands. A status list answers that as one bit per credential in a single compressed, signed document: the verifier fetches the whole list and reads its own bit, so the issuer never learns which credential was being asked about. The privacy property comes from the shape of the answer, not from a promise.
- Gloss of IETF Token Status List. This site’s own claim: /trust-fabric · served by this cell: /t/root/status/1
- DID — decentralized identifier
- Also searched as: did, decentralized identifier, did:web, did web, identifier, who signed it, public key
- An identifier that resolves to a document containing public keys. The method decides how that resolution happens. did:web makes the identifier a domain name and serves the document at a well-known path, so resolving it is an ordinary HTTPS fetch anyone can perform and nobody needs a ledger, a token or a permissioned network to complete.
- Gloss of W3C DID Core 1.0; method did:web. This site’s own claim: /standards · served by this cell: /.well-known/did.json · /t/root/did.json
- How a credential reaches a wallet
- Also searched as: oid4vci, issuance, issue, get a credential, openid4vci, how do i receive, onboarding a credential
- The protocol a wallet uses to collect a credential from an issuer: the wallet discovers what the issuer offers from a well-known metadata document, obtains authorization, and requests the credential over an ordinary OAuth-shaped exchange. Being ordinary is the feature — it means an issuer does not need a bespoke wallet and a wallet does not need a bespoke issuer.
- Gloss of OpenID for Verifiable Credential Issuance (OpenID4VCI). This site’s own claim: /standards · served by this cell: /.well-known/openid-credential-issuer · /.well-known/oauth-authorization-server
- How a credential is presented
- Also searched as: oid4vp, presentation, present, show a credential, openid4vp, dcql, prove something, log in with a credential
- The protocol a verifier uses to ask for credentials and a wallet uses to answer. The verifier states what it needs as a query rather than naming a provider, and the wallet responds with a presentation bound to that specific request — so a captured answer cannot be replayed at a different verifier.
- Gloss of OpenID for Verifiable Presentations (OpenID4VP), with DCQL for the query. This site’s own claim: /standards
- Wallet
- Also searched as: wallet, where is it stored, app, phone, my credentials, hold
- The software the holder keeps credentials in, and the place the holder’s keys are created and stay. The property that matters is not the interface: it is that the private key is generated on the device and never leaves it, because a key held by the provider makes the provider the holder no matter what the screen says.
- Gloss of No single specification; the relevant ones are OpenID4VCI/VP for the protocols and the platform key stores for custody. This site’s own claim: /for-people
- What this site is
- Also searched as: orbis, what is orbis, what does this do, what is this, the platform, product, what do you do, help
- This surface will not summarise the product for you, because a summary is exactly the kind of claim this site refuses to make without a receipt. What it will do is hand you the register: the capability page states what is live, what is partial and what is not built, each one linked to the endpoint that proves it.
- Gloss of Not a specification — a register. This site’s own claim: /capabilities · served by this cell: /openapi.json · /build
- The standards
- Also searched as: standards, specifications, specs, interoperable, eidas, regulation, compliance, conformance
- Verifiable credentials are not one standard but a stack: a data model, a serialization, a protocol to issue, a protocol to present, a way to identify keys and a way to publish status. Interoperability claims are only meaningful per layer, which is why a page that claims the whole stack at once is telling you nothing.
- Gloss of W3C VC 2.0, IETF SD-JWT VC, OpenID4VCI/VP, W3C DID Core, IETF Token Status List. This site’s own claim: /standards · served by this cell: /conformance/vectors