Assurance, identity and law: what each control proves

The problem: a valid signature, but whose?

Mariama has signed a loan contract. Ibrahima opens the PDF and every check from Articles 1 to 7 passes: the signature verifies, the certificate chains to a trusted root and is not revoked, and a timestamp shows when the document existed.

None of that tells him the person who pressed “sign” was Mariama, or what a court in Conakry would make of the signature. The first question is about assurance: how confident you can be in a claimed identity. The second is about law.

Legal signature, technical signature

An electronic signature is a legal notion; a digital signature is a cryptographic mechanism, one way to produce it (How a digital signature works). The mechanism proves that the holder of a private key signed those exact bytes. Without a trusted link from key to person, forging a signature reduces to “falsely claiming an identity” (FIPS 186-5, §3).

A vocabulary for assurance

NIST’s Digital Identity Guidelines, SP 800-63-4, give a detailed vocabulary for identity assurance. It is a US federal guideline that “may be used by nongovernmental organizations on a voluntary basis” (SP 800-63-4, Authority), with no legal status in Guinea. We use its words, not its rules.

It separates two activities that Article 5 introduced (the signing transaction):

• Identity proofing: “The processes used to collect, validate, and verify information about a subject to establish assurance in the subject’s claimed identity.”
• Authentication: “The process by which a claimant proves possession and control of one or more authenticators bound to a subscriber account to demonstrate that they are the subscriber associated with that account” (glossary).

In our gloss: proofing answers “who is this?” once, at enrollment; authentication answers “is this the same account holder?” every time. Strong authentication on a weakly proofed account still says nothing about a real-world name.

It grades assurance in three families, identity (IAL), authenticator (AAL) and federation (FAL) assurance, each with three levels (§1).

Identity proofing: resolution, validation, verification

SP 800-63A-4 splits proofing into three steps (SP 800-63A-4, §2.1.1):

1. Resolution. Collect evidence and attributes, and uniquely distinguish the person.
2. Validation. Check that the evidence is authentic, valid and accurate, and check the attributes against authoritative or credible sources.
3. Verification. Confirm that the applicant is “the genuine owner of the presented identity evidence”.

Enrollment follows, and authenticators are bound to the new account.

The levels differ in how much of this they demand (§1.2, §4.3). With no identity proofing, there is no requirement to link the applicant to a real person. IAL1 supports real-world existence and gives “some assurance”. IAL2 adds more evidence and stronger validation and verification, remote or on-site. IAL3 requires an on-site attended session with a trained proofing agent and at least one biometric, which it “SHALL collect and retain … to support account recovery and non-repudiation”.

ID documents, face match and liveness

Checking an ID card is validation: the document looks genuine and its data match a source. It does not show that the person holding it owns it (§2.1.1, §2.5).

SP 800-63A-4 lists the verification methods: a confirmation code, authenticating to an existing account, a microtransaction, a visual face comparison (on-site, remote or later), and automated biometric comparison. It rules one out: “Knowledge-based verification (KBV) … SHALL NOT be used for identity verification” (§2.5.1).

A face match raises a further question: is a live person in front of the camera, or a photo or mask? That is liveness, which NIST calls presentation attack detection (PAD). For remote biometric collection the provider “SHALL implement presentation attack detection (PAD)” to “confirm the genuine presence of a live human being”, with an impostor attack presentation accept rate (IAPAR) below 0.07, tested to ISO/IEC 30107-3:2023 (§3.11).

Even a strong match holds only at proofing time. It does not say that person later consented to a particular document (our reasoning).

A channel is not an identity

Most signing flows reach the signer by email or phone. Each proves less than it seems.

Email. A confirmation code confirms “access to a postal address, email address, or phone number for the purposes of future communications” (§3.8). Only codes to a postal or phone address can also count as identity verification, and only when that address was validated as associated with the identity evidence, not merely typed in (§4.1.6, §4.2.6.1). Email is not an authenticator channel either: “Email SHALL NOT be used for out-of-band authentication”, and codes that validate an email address “are not authentication processes” (SP 800-63B-4, §3.1.3.1).

SMS and voice. A phone-network code, valid for at most 10 minutes, shows someone controlled that number or SIM at that moment. It is a “restricted authenticator”: verifiers shall offer alternatives and should check for “device swap, SIM change, number porting” (§3.1.3.2, §3.1.3.3, §3.2.9).

Phishing resistance is not required at AAL1, must be available at AAL2, and is required at AAL3 (§2). Article 2 made the same point in OTP ≠ legal identity.

Sole control

The last question is about the key, not the person: who could have used it? An HSM keeps a key inside the device but does not decide who may ask it to sign (HSM ≠ authorization). A certificate binds a key to a name; it does not show the key stayed under that person’s control.

What each control proves

Side by side, each control proves one narrow thing, and none proves everything.

A table of eight controls, each with what it shows and what it does not show. Email code: mailbox access, not identity. SMS code: control of a number at a moment, not identity. ID document check: the document looks authentic, not that the holder owns it. Face match with liveness: a live person matches the portrait, not consent to a document. Certificate: the issuer binds a key to a name, not who pressed sign. Signature: the key holder signed those bytes, not identity or intent. Timestamp: the hash existed by time T, not who signed or when they acted. Audit trail: the record was not altered after sealing, not that its events are true.

Control	Shows	Does not show
Email code or link	Someone could read that mailbox within the validity window	Legal identity; that the mailbox owner signed; not an authenticator
SMS or voice code	Someone controlled that number or SIM at that moment	Legal identity, unless the number was validated against identity evidence; safety from SIM swap
ID document check	The document looks authentic and its data match a source	That the person presenting it owns it
Face match with liveness	A live person matches the portrait, to a measured error rate	Consent to a given document; anything after proofing time
Certificate	The issuer asserts a binding between a public key and a name	Who pressed sign; that the key stayed under sole control
Cryptographic signature	The holder of that private key signed those exact bytes	Identity without a certificate; intent
Timestamp (RFC 3161)	The hash existed at or before time T, per the TSA	Who signed; when the signer acted; the content
Hash-chained audit trail	The recorded events were not altered after sealing	That the recorded events are true; identity beyond what was captured

• Email code or link

  Shows

  Someone could read that mailbox within the validity window

  Does not show

  Legal identity; that the mailbox owner signed; not an authenticator

• SMS or voice code

  Shows

  Someone controlled that number or SIM at that moment

  Does not show

  Legal identity, unless the number was validated against identity evidence; safety from SIM swap

• ID document check

  Shows

  The document looks authentic and its data match a source

  Does not show

  That the person presenting it owns it

• Face match with liveness

  Shows

  A live person matches the portrait, to a measured error rate

  Does not show

  Consent to a given document; anything after proofing time

• Certificate

  Shows

  The issuer asserts a binding between a public key and a name

  Does not show

  Who pressed sign; that the key stayed under sole control

• Cryptographic signature

  Shows

  The holder of that private key signed those exact bytes

  Does not show

  Identity without a certificate; intent

• Timestamp (RFC 3161)

  Shows

  The hash existed at or before time T, per the TSA

  Does not show

  Who signed; when the signer acted; the content

• Hash-chained audit trail

  Shows

  The recorded events were not altered after sealing

  Does not show

  That the recorded events are true; identity beyond what was captured

A certificate is only as strong as its issuer’s proofing. A time-stamping authority does not examine the imprint it signs and must not include requester identification (RFC 3161, §2.1), so a timestamp never says who signed (Article 7).

Assurance comes from stacking rows: proofing for who enrolled, authentication for who came back, a binding to the document (Article 5), a signature and certificate for the bytes, a timestamp and audit trail for when and what.

Guinean law on its own terms

This article quotes excerpts from Loi L/2016/035/AN relative aux transactions électroniques (28 July 2016), whose article 3 keeps non-contrary rules of « le Code civil en vigueur ». Later texts also bear on the question, including provisions of the Code civil itself; how they combine is for a Guinean lawyer. Translations are ours; we do not interpret legal effect.

What a signature is. Article 1 defines « Signature Electronique » as « toute donnée qui résulte d’un procédé fiable d’identification, de nature à garantir ou authentifier son lien avec l’acte auquel elle s’attache » (art. 1): any data resulting from a reliable identification process, capable of guaranteeing or authenticating its link with the act. Article 33 adds that a signature « permet de conférer » « une valeur juridique, une validité, une régularité, et une authenticité à un acte juridique », and in electronic transactions shows « l’adhésion, l’accord ou le consentement des parties » (art. 33).

Article 1 does not define « signature électronique sécurisée », « certificat qualifié », « certificat numérique » or « mécanisme sécurisé de création ». For undefined terms, it points elsewhere: « les définitions données par les instruments juridiques de la CEDEAO, de l’Union Africaine ou de l’Union Internationale des Télécommunications prévalent sur toutes autres définitions ».

Article 34. It has five paragraphs (the scan does not number them; the count is ours). We give each, in order, and draw no hierarchy between them.

1. « Une signature électronique créée par un dispositif fiable et sécurisé que le signataire peut garder sous contrôle et utilisation exclusifs et qui repose sur un certificat numérique est admise ou çonsidérée [sic] comme une signature valable au même titre que la signature manuscrite. » A signature from a reliable, secure device under the signatory’s exclusive control and use, resting on a digital certificate, is admitted or considered valid on the same basis as a handwritten one.
2. « La fiabilité d’un procédé ou dispositif de signature électronique est présumée jusqu’à preuve du contraire, à condition que : ce procédé ou dispositif mette en œuvre une signature électronique sécurisée, établie grâce à un mécanisme sécurisé de création de signature électronique ; la vérification de cette signature repose sur l’utilisation d’un certificat qualifié. » Reliability is presumed, until proven otherwise, when the process uses a secure signature made with a secure creation mechanism and verification relies on a qualified certificate.
3. « Les conditions permettant de qualifier une signature électronique comme étant « sécurisée », seront définies par un décret du président de la République. » The conditions for « sécurisée » are left to a presidential decree.
4. « Une signature électronique ne peut être déclarée irrecevable au seul motif : qu’elle se présente sous forme électronique ; ou qu’elle ne repose pas sur un certificat qualifié ; ou qu’elle n’est pas créée par un mécanisme sécurisé de création de signature électronique. » A signature may not be declared inadmissible solely because it is electronic, lacks a qualified certificate, or was not made with a secure creation mechanism.
5. « La signature électronique sécurisée liée à un certificat électronique qualifié, a la même force ou valeur probante que la signature est [sic] manuscrite. » A secure signature linked to a qualified certificate has the same probative force or value as a handwritten one.

Paragraph 1 speaks of a « certificat numérique »; paragraph 5 of a « certificat électronique qualifié ». Both use handwritten-signature wording, with different conditions. How they relate is a question for a Guinean lawyer (art. 34).

Around article 34. Electronic writing is admitted as evidence on the same basis as paper, « à condition toutefois que la personne dont il émane soit identifiée ou puisse être identifiée, et qu’il puisse être conservé dans des conditions de nature à garantir son intégrité ou son authenticité » (art. 21). Its second paragraph disapplies the first for private deeds on family law and successions, and on securities unless made for professional needs. A required handwritten mention may be made electronically « si les conditions de cette apposition sont de nature à garantir qu’elle ne peut être effectuée que par lui-même » (art. 27). Signing electronically « est optionnelle et facultative, et dépend de la volonté de chaque partie » (art. 36). Unless a law sets a shorter period, electronic documents are kept for ten years, in a form showing the sent and kept documents are « strictement identiques », with origin, destination, and times of sending or receipt where they exist (art. 37). We found no article on electronic timestamps.

Who regulates. Article 43 entrusts regulation, « sauf dispositions légales contraires », to « l’Autorité Administrative en charge de la Régulation des Postes et Télécommunications » (decree D/2026/0160 art. 4 charges the ARPT with its execution). Article 44 has that authority audit and certify the systems of those doing electronic transactions, and issue « les certificats électroniques en République de Guinée ».

The 2026 decrees. Two decrees of 21 May 2026 concern the security audit and certification of information systems used for electronic transactions. D/2026/0159 applies articles 44 and 46; it says nothing about the legal effect of signatures, certificate tiers or identity proofing (D/2026/0159). The « certificat de conformité » it lets the ARPT issue certifies an information system’s security, not a signature (art. 13). D/2026/0160 adopts a certification référentiel « tel qu’annexé » (D/2026/0160, art. 1), but the published PDF has no annex.

Mariama signs, Ibrahima asks who

Back to the loan, as a generic flow. Ibrahima’s file holds a PAdES signature that verifies, a certificate chain, a timestamp and a sealed audit trail. Suppose the flow, whoever runs it, also sent Mariama a code by SMS.

Row by row: that key signed those bytes; the issuer bound it to a name; the hash existed by the timestamp’s time; the record was not changed after sealing; someone controlled Mariama’s number when the code was typed. He cannot say it was Mariama unless her account was proofed and the number validated against her identity evidence. Nor does the matrix tell him the signature’s legal value in Guinea; that is a question for his lawyer.

For a 5,000,000 GNF loan between businesses that know each other, he may decide that is enough. For a larger deal, he may add proofing. That is a risk decision.

Decision checklist

Work through these before choosing controls for a type of document.

1. Does electronic writing count as evidence for it? Article 21 al. 2 disapplies al. 1 for family law, successions and non-professional securities. Does anything require the electronic form (art. 36)?
2. Is a handwritten mention required? The conditions must guarantee only the person bound could add it (art. 27).
3. Whom must you name later, and how sure must you be? Pick a proofing depth. A document check alone is validation, not verification. See how much proof your document needs.
4. How does the signer come back to sign? Not email as an authenticator; SMS as restricted; phishing resistance if the stakes call for it.
5. Is the approval bound to this document’s digest? (Article 5.)
6. Whose key signs, under whose control? (Article 3.) Whether a setup meets article 34’s control wording is a legal question.
7. Can someone check it without you? Chain, revocation and a standard format (Article 4, Article 6).
8. Will it verify years later? Timestamps and embedded validation data (Article 7).
9. Can you keep it for the period art. 37 sets (ten years, unless a law sets less), identical, with origin, destination and times? (Art. 37.)
10. Which open question touches it? Ask a lawyer admitted in Guinea before relying on an answer.

Where SEDEYA fits

In the matrix, SEDEYA’s part is the last three rows: the signature, the RFC 3161 timestamp embedded with it, and the sealed audit trail. It signs PDFs in PAdES up to B-LTA, with RFC 3161 timestamps and embedded validation data, and seals a hash-chained audit trail into the signed PDF. Signing keys are held in an HSM (PKCS#11) or a KMS. Anyone can check a signed document on the public verification page, by upload or QR code. Which identity checks it needs, and its legal weight, are decisions for the parties and their lawyers. The next article in this series puts these pieces into one production architecture. For our plain-language post on the Guinean rules of evidence for electronic signatures, see what Guinean law says about electronic signatures.

Risks and misconceptions

Summary

• A signature proves a key signed bytes. Who holds the key is assurance; what the signature is worth is law.
• NIST SP 800-63-4 separates identity proofing from authentication. It is a voluntary vocabulary, not Guinean law.
• A document check is validation; verification, such as a face match with liveness, ties it to the person.
• Email and SMS codes prove control of a channel; on their own, not identity.
• L/2016/035/AN defines electronic signature neutrally; how article 34’s paragraphs relate is still open. eIDAS is a separate framework.

Check your understanding

Check your understanding

A flow checks the signer's ID card photo against a government database and finds it valid. Which NIST step has it done, and which is missing?

Show the answer

Validation: the evidence is authentic and its data match a source. Verification is missing: nothing shows the person presenting the card is its owner. A face comparison with presentation attack detection is one way to add it.

Check your understanding

Can you tell from Guinean law alone whether an OTP-and-signature flow gets handwritten-equivalent value?

Show the answer

No. Article 34 has two paragraphs with handwritten-signature wording, under different conditions; how they relate, and what « sécurisée » means, are open. Article 34 al. 4 does say a signature may not be refused solely for being electronic or lacking a qualified certificate. Applying it to a given flow is a question for a lawyer admitted in Guinea.

Next step

Article 9 puts the series into one production architecture. Meanwhile, talk to us and we will show you a SEDEYA-signed PDF, its sealed audit trail, and how anyone can verify it.