All notes · Essays
Passkey signatures as evidence in Japan
How Japanese law treats signatures and electronic signatures, where a passkey signature fits, what is still undecided, and what a product needs to add around it.
The starting point: proving a document is genuine
In Japanese civil litigation, the party relying on a document has to prove that it was genuinely made by the person it is attributed to. The Code of Civil Procedure then gives a shortcut: a private document bearing the person's signature or seal impression is presumed to be genuine1. That second clause is where the hanko has done its work for decades.
Electronic records got their own version of the shortcut in the Act on Electronic Signatures and Certification Business.
What the Electronic Signatures Act says
Article 2 defines an electronic signature as a measure applied to information that does two things: it shows that the information was created by the person who applied the measure, and it makes it possible to confirm whether the information has been altered2.
Article 3 then presumes that an electronic record was genuinely made when it carries the person's own electronic signature. It applies only to signatures that, through proper management of the codes and objects needed to make them, only that person can make2.
The government's Q&A on Article 3, revised in January 2024, reads two requirements into this. The code used for the signature must be one that others cannot easily reproduce (uniqueness), and the signature must be made on the person's own instruction3. The Q&A addresses services that sign with the provider's own key on the user's instruction. For those, it asks for sufficient uniqueness both in how the user is authenticated and in the provider's internal process, and gives two-factor authentication as an example3.
Where a passkey signature fits
A passkey signature is made with a private key held on the user's device. The key doesn't leave the authenticator, and each signature passes a local check: a face, a fingerprint, or a PIN4. In Clavis, what gets signed is a hash of the operation, and the one line shown to the user (product name, verified host, operation name) is bound into the signature as well.
Against Article 2, that is close to the shape the definition describes: the signature points to the key holder, and any change to the signed content breaks it.
Against Article 3, it is strong on uniqueness: a key held by the authenticator plus a local check is two factors in one gesture. The open questions are elsewhere.
- Synced passkeys. A passkey that syncs across a person's devices, or a device shared within a family, weakens the claim that only that person could have signed. The authenticator reports whether a credential is eligible for backup4; whether to record that, or to accept only device-bound passkeys, is a product decision.
- Who the key belongs to. The presumption assumes the signature is the person's own. A passkey proves possession of a key, not a legal identity. Linking the key to a named person is the job of your identity checks at registration.
Whether the Article 3 presumption extends to passkey signatures is not settled by any primary source we have found. In the end, a court decides on the facts.
What to add around the signature
- Identity. Record how and when you verified the person who registered the passkey. Put a reference to that check (not the personal data itself) into the content being signed, so the signature binds it too.
- The content itself. Keep what was signed, not only its hash. A hash alone can't show what someone agreed to once the content is gone.
- Time. Anchoring records in a ledger with a third-party timestamp makes it easier to show that a record existed at a point in time5.
- A plain description. When you explain a passkey signature to a counterparty or a court, describe what it does and doesn't show. Overclaiming invites the argument you least want.
In one sentence
A passkey signature is a record, checkable later, that a particular passkey signed this content at this time. Who stood behind the passkey, and whether the content meets any legal requirement for writing, depends on your own procedures for identity, consent, and retention.
Next
Sources
- Code of Civil Procedure, Article 228 (e-Gov) · Checked 2026-10-10
- Act on Electronic Signatures and Certification Business, Articles 2 and 3 (e-Gov) · Checked 2026-10-10
- Digital Agency and Ministry of Justice, Q&A on Article 3 of the Electronic Signatures Act (revised 9 January 2024, in Japanese) · Checked 2026-10-10
- W3C Web Authentication Level 3 · Checked 2026-10-10
- RFC 3161 Time-Stamp Protocol · Checked 2026-10-10
Colophon
- Edition
- Edition 1
- Published
- 2026-10-11
- Signed
- Rin.Natsume · Passkey · 2026-10-11 18:03 UTC · Signature file · Source
- Seal
- sha256 -sezFC1nnmLKuYMod5YvoaCW-JeSGsKHtpabOlX1BEs
- Publisher
- DeepDive, Inc.
The signature shows who stands behind this edition and that the source hasn't changed since it was signed. It does not show that the content is correct.
This is not legal advice. How it applies depends on the facts and the jurisdiction.