Network Working Group S. Uimonen Internet-Draft Independent Intended status: Informational 15 October 2026 Expires: 15 April 2027 Verified Email Identity Framework (VEIF) draft-uimonen-veif-02 Abstract This document defines the Verified Email Identity Framework (VEIF), an experimental framework for adding accountable, verified sender identity to Internet email. VEIF complements existing email authentication mechanisms such as SPF, DKIM, and DMARC. Those mechanisms establish authorization, message integrity, and domain alignment, but do not by themselves establish that a sender identity is associated with a verified real-world entity. VEIF uses an SD-JWT-based Verifiable Digital Credential (SD-JWT VC) to bind a pseudonymous sender identity and a sender-controlled cryptographic key to an identity verified by an Identity Provider (IdP). A separate VEIF message signature binds that credential to the email message. The recipient does not normally receive the sender's real-world identity. Instead, VEIF provides technical accountability: where an appropriate legal or otherwise authorized process exists, the Identity Provider can establish the real-world entity to which the sender credential was issued. This document intentionally does not define a global identity authority, a legal identification procedure, or a mandatory trust hierarchy. Trust and identity disclosure policies remain matters for receiving organizations, Identity Providers, jurisdictions, and deployment environments. This version is experimental and is intended to enable discussion, implementation experimentation, and interoperability testing. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 15 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 2. Scope 3. Terminology 3.1. Verified Entity 3.2. Identity Provider 3.3. VEIF Identity Credential 3.4. Sender Key 3.5. Accountability 3.6. Message Binding 3.7. VEIF-Signature 4. Architecture 4.1. Overview 4.2. Relationship to Existing Email Authentication 4.3. Issuer, Holder, and Verifier Roles 5. VEIF Identity Credential 5.1. Credential Format 5.2. VEIF Credential Type 5.3. Required Credential Claims 5.4. Identity Assurance 5.5. Accountability Binding 5.6. Key Binding 5.7. Selective Disclosure 6. Credential Issuance 6.1. General Requirements 6.2. Email Address Binding 6.3. Organizational Senders 6.4. Delegation 7. VEIF Message Signature 7.1. Purpose 7.2. Header Field 7.3. JWS Header 7.4. JWS Payload 7.5. Credential Transport 7.6. Header Canonicalization 7.7. Body Canonicalization 7.8. Required Signed Headers 7.9. Binding to the Sender Address 8. Message Signing Procedure 9. Message Verification Procedure 10. VEIF Authentication Results 10.1. General 10.2. Suggested Result Values 10.3. Identity Information 11. Trust Model 11.1. No Global Trust Anchor 11.2. Issuer Key Discovery 11.3. Domain Authorization 11.4. Multiple Identity Providers 12. Credential Status and Revocation 12.1. General 12.2. Status Mechanisms 12.3. Compromised Sender Keys 13. Privacy Considerations 13.1. No Mandatory Public Identity 13.2. Pseudonymous Subjects 13.3. Accountability Without Disclosure 13.4. Data Minimization 13.5. Header and Credential Leakage 14. Security Considerations 14.1. Identity Misbinding 14.2. Compromised Credentials 14.3. Compromised Identity Provider 14.4. Replay 14.5. Message Modification 14.6. Header Injection 14.7. Algorithm Agility 14.8. Sender Identity Versus Human Actor 14.9. Denial of Service 14.10. Trust Downgrade 15. Forwarding and Intermediaries 16. Relationship to Credential Standards 16.1. SD-JWT VC 16.2. SD-JWT and Key Binding 16.3. W3C Verifiable Credentials 17. Deployment Model 17.1. Incremental Deployment 17.2. No Requirement for Universal Adoption 17.3. High-Assurance Applications 18. Example 19. Example Authentication Results 20. IANA Considerations 20.1. VEIF-Signature Header 20.2. VEIF-Credential Header 20.3. Authentication-Results 20.4. VEIF Credential Type 21. Implementation Considerations 22. Open Issues for Further Work 23. Design Principle 24. References 24.1. Normative References 24.2. Informative References 25. Acknowledgements Author's Address 1. Introduction Email authentication has traditionally concentrated on the authorization of domains and mail infrastructure. SPF [RFC7208] allows a receiving system to determine whether a sending host is authorized to transmit mail for a domain. DKIM [RFC6376] provides a cryptographic signature over selected message header fields and the message body and thereby provides message integrity and domain-associated signing authority. DMARC [RFC7489] allows a receiver to apply policy based on domain authentication and alignment. These mechanisms remain important. However, they do not establish that the entity operating a particular sender address has been associated with a verified real-world identity. VEIF addresses this additional property. The fundamental distinction made by VEIF is between: o Authentication: the message is cryptographically associated with an authenticated sender identity or domain. o Verification: the sender identity has been associated by an Identity Provider with a verified real-world entity. o Accountability: if the message is subsequently associated with fraud, abuse, phishing, or other unlawful activity, the entity behind the verified sender identity can be established through an appropriate authorized or lawful process. VEIF therefore does not require the recipient to learn the sender's civil identity. A concise description of the intended privacy property is: "Private to the recipient, accountable to the appropriate authority." VEIF is an additional identity layer. It does not replace SPF, DKIM, DMARC, SMTP authentication, S/MIME, ARC, or other existing email security mechanisms. 2. Scope This document defines: o the VEIF identity and accountability model; o the use of an SD-JWT VC as the VEIF identity credential; o the cryptographic binding between the credential and the sender key; o the VEIF-Signature and VEIF-Credential message header fields; o the message-binding signature format; o credential and message validation requirements; o trust, privacy, and accountability considerations; and o an experimental deployment model. This document does not define: o a global Identity Provider; o a mandatory identity-verification procedure; o a government identity database; o a global trust hierarchy; o a legal definition of identity; o a mandatory disclosure procedure; o a requirement that the recipient learn the sender's real-world identity; o a replacement for SPF, DKIM, or DMARC; or o a general-purpose digital identity system outside email. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3.1. Verified Entity A Verified Entity is a natural person or legal entity whose identity has been established by an Identity Provider according to an identity-assurance policy. A Verified Entity is not necessarily the physical person who generated every message. An account may be operated by an authorized employee, agent, automated system, or other delegate. 3.2. Identity Provider An Identity Provider (IdP) is an entity that verifies a real-world entity and issues an SD-JWT VC satisfying the VEIF credential profile. VEIF does not define which organizations are eligible to operate as IdPs. 3.3. VEIF Identity Credential A VEIF Identity Credential (VIC) is an SD-JWT VC conforming to the requirements in Section 5. The VIC is not a new credential format. It is an SD-JWT VC with additional VEIF profile requirements. 3.4. Sender Key The Sender Key is the cryptographic key pair controlled by the sender or by an authorized sending system. The public key is identified by the `cnf` claim of the VIC. 3.5. Accountability Accountability is the property that an authenticated VEIF sender can be associated with a Verified Entity through the Identity Provider that issued the credential, subject to the IdP's records, applicable policy, and any applicable legal or authorized process. 3.6. Message Binding Message Binding is the cryptographic association between a VIC and a particular email message. 3.7. VEIF-Signature VEIF-Signature is the experimental email header field defined by Section 7. It carries a JWS Compact Serialization that binds the message to the sender key identified by the VIC. 4. Architecture 4.1. Overview VEIF introduces an identity layer above domain and transport authentication. The conceptual relationship is: Verified Entity | | identity verification v Identity Provider | | issues SD-JWT VC v VEIF Identity Credential | | binds identity to sender public key v Sender Key | | signs message v VEIF-Signature | v Email | v Receiving System The receiver independently evaluates: o domain authorization; o message integrity; o domain alignment; o VEIF credential validity; o VEIF message signature validity; o IdP trust; and o local policy. 4.2. Relationship to Existing Email Authentication VEIF is complementary to existing email authentication. A typical message may therefore produce results such as: SPF = pass DKIM = pass DMARC = pass VEIF = pass These results have different meanings. SPF indicates authorization of the sending infrastructure. DKIM provides message signing and domain-associated signing authority. DMARC evaluates domain alignment and policy. VEIF indicates that the message has been cryptographically bound to an identity credential issued for a verified entity and that the sender demonstrated control of the corresponding sender key. A VEIF implementation MUST NOT interpret VEIF success as replacing SPF, DKIM, or DMARC. 4.3. Issuer, Holder, and Verifier Roles VEIF uses the general issuer/holder/verifier model associated with verifiable digital credentials. The IdP is the issuer. The sender, or a sending system acting on the sender's behalf, is the holder and key controller. The receiving mail system is the verifier. In organizational deployments, the holder may be an automated mail system while the Verified Entity is a legal entity or organization. 5. VEIF Identity Credential 5.1. Credential Format A VEIF Identity Credential MUST be encoded as an SD-JWT VC as defined by [SD-JWT-VC]. SD-JWT VC uses the `application/dc+sd-jwt` media type. VEIF does not define a new credential serialization. VEIF implementations MUST implement the validation rules applicable to SD-JWT VCs, including the SD-JWT processing rules in [RFC9901], and MUST additionally apply the VEIF profile requirements defined in this document. 5.2. Credential Type The SD-JWT VC `vct` claim identifies the credential type and MUST be a Collision-Resistant Name. For this experimental version, VEIF uses the following UUID URN: urn:uuid:4c4f4663-6d52-4f2b-a987-8cb17fb10019 This value identifies the VEIF Identity Credential type. It is intentionally not a claim or namespace defined by VEIF itself; it is a collision-resistant type identifier as required by SD-JWT VC. A future version of VEIF MAY define a different credential type identifier and associated type metadata. 5.3. Required Credential Claims A VEIF Identity Credential MUST contain the following claims: o `vct` -- the VEIF credential type identifier; o `iss` -- the Identity Provider identifier; o `sub` -- the VEIF sender identity identifier; o `cnf` -- the sender public key; o `iat` -- the issuance time; and o `jti` -- a unique credential instance identifier. The registered JWT claims used by VEIF, including `iss`, `sub`, `iat`, `exp`, `nbf`, and `jti`, follow the definitions in [RFC7519]. The credential SHOULD contain `exp` and MAY contain `nbf`. The `cnf` claim MUST identify the public key used for VEIF message signing. The `cnf` claim uses the confirmation-key semantics defined in [RFC7800]. It is therefore REQUIRED by the VEIF profile even though it is optional in the general SD-JWT VC format. The `jti` claim MUST uniquely identify the credential instance. The `sub` claim SHOULD be pseudonymous and SHOULD NOT directly contain unnecessary personally identifying information. 5.4. Identity Assurance A VEIF credential MUST contain an assurance indication using the following VEIF-specific claim: `veif_assurance` The value is a string defined by the issuing IdP's assurance policy. Example: "veif_assurance": "substantial" Implementations MUST NOT interpret an assurance value as having universal legal meaning. Two IdPs using the same textual value MUST NOT be assumed to provide equivalent identity verification unless the receiving system's trust policy establishes that equivalence. Future versions of VEIF MAY define interoperable assurance levels. 5.5. Accountability Binding The IdP MUST maintain sufficient records to associate the credential instance with the Verified Entity according to the IdP's accountability policy. The mapping is an IdP-side record and MUST NOT be required to be disclosed to the recipient. The VEIF protocol does not prescribe the form of that record. The mapping MAY contain the credential identifier, pseudonymous subject identifier, verified entity, identity verification evidence, issuance and expiry information, sender authorization information, and delegation records. The IdP SHOULD minimize retention of personal data and SHOULD retain only the information necessary for the applicable accountability policy. 5.6. Key Binding The `cnf` claim in the VEIF credential identifies the public key corresponding to the private key used to create the VEIF message signature. The IdP MUST sign the credential in such a way that the `cnf` claim is integrity protected. A verifier MUST verify that the VEIF message signature was generated using the private key corresponding to the public key identified by `cnf`. This provides the following cryptographic chain: IdP signature: Verified Entity -> VEIF subject -> Sender public key Sender signature: Sender private key -> specific email message A verifier MUST NOT regard the second signature alone as proof of verified identity. 5.7. Selective Disclosure VEIF SHOULD use selective disclosure as defined by [RFC9901] where it reduces unnecessary disclosure of sender information. In particular, the sender's real-world identity SHOULD NOT be disclosed merely because a VEIF credential is used. A receiving system MUST NOT require disclosure of personally identifying claims merely to determine that a valid VEIF credential exists unless such disclosure is part of its explicit local policy. 6. Credential Issuance 6.1. General Requirements Before issuing a VEIF Identity Credential, an IdP MUST establish: o the identity of the Verified Entity according to its assurance policy; o the entity's authorization to use the sender identity for which the credential is issued; and o the public key to which the credential will be bound. The exact identity verification procedure is outside the scope of VEIF. 6.2. Email Address Binding A VEIF credential SHOULD be associated with a specific sender identity, mailbox, or sending authorization. An IdP MUST NOT issue a credential for an email identity merely because the applicant controls an unrelated domain. Appropriate proof of authorization MAY include mailbox control, domain-level authorization, an authorization assertion from the mailbox provider, organizational authorization, or another mechanism accepted by the IdP's policy. 6.3. Organizational Senders VEIF MUST support credentials issued to legal entities and other organizations. In such cases, the accountable entity is the organization rather than necessarily an individual human. An organization MAY authorize multiple senders or sending systems to use the same credential or a set of credentials. Deployments SHOULD provide a mechanism for identifying the authorized agent or sending system internally. 6.4. Delegation A Verified Entity MAY delegate message generation to another system or person. Delegation MUST NOT be interpreted as changing the Verified Entity unless a new credential is issued or the credential explicitly represents the delegate. 7. VEIF Message Signature 7.1. Purpose The VEIF-Signature header field binds a VEIF Identity Credential to an email message. The signature demonstrates possession of the private key identified by the credential's `cnf` claim at the time the message was signed. VEIF-Signature does not replace DKIM. 7.2. Header Field The experimental header field is: VEIF-Signature: The field body contains a JWS Compact Serialization as defined by [RFC7515]. The JWS Protected Header MUST contain `alg` and SHOULD contain: "typ": "veif+jws" Example: {"alg":"ES256","typ":"veif+jws"} The JWS MUST use a digital signature algorithm other than `none`. During the experimental phase, implementations MUST support ES256. 7.3. JWS Payload The JWS payload MUST be a JSON object containing the following members: `v` VEIF message signature version. The value is 1. `cred_hash` Base64url-encoded SHA-256 digest of the exact unfolded VEIF-Credential field value. `iat` NumericDate indicating when the message signature was generated. `hc` Header canonicalization algorithm. The value is `simple` or `relaxed`. `bc` Body canonicalization algorithm. The value is `simple` or `relaxed`. `h` Ordered array of message header field names covered by the signature. `hh` Base64url-encoded SHA-256 digest of the canonicalized selected message header fields. `bh` Base64url-encoded SHA-256 digest of the canonicalized message body. The payload MAY contain: `exp` NumericDate after which the message signature is not intended to be accepted. Example payload: { "v":1, "cred_hash":"m8K3...base64url...", "iat":1791379200, "hc":"relaxed", "bc":"relaxed", "h":["From","To","Date","Subject","Message-ID"], "hh":"x7p2...base64url...", "bh":"A4m9...base64url..." } JSON member ordering is not semantically significant because the complete payload is protected by JWS. 7.4. Credential Transport The complete SD-JWT VC used for the message MUST be made available to the verifier. During the experimental phase, the recommended transport is the following message header field: VEIF-Credential: The value MUST be the compact SD-JWT VC serialization defined by [SD-JWT-VC]. The field MAY be folded according to the Internet Message Format rules [RFC5322]. A sender MUST ensure that each transmitted line conforms to the applicable Internet Message Format line-length requirements. A future version MAY define an authenticated credential retrieval mechanism. Such a mechanism is outside the scope of this version. A verifier MUST calculate `cred_hash` over the exact unfolded field value of VEIF-Credential, excluding only the whitespace introduced by header folding. 7.5. Header Canonicalization VEIF uses the `simple` and `relaxed` canonicalization algorithms defined by DKIM [RFC6376]. The `hc` value MUST be either `simple` or `relaxed`. The selected message header fields MUST be canonicalized in the order specified by `h`. Each canonicalized header field MUST be terminated by CRLF before being included in the hash input. Header field name matching is case-insensitive for the purpose of selecting fields. Header field selection and duplicate-field processing MUST follow the DKIM rules in [RFC6376]. In particular, a verifier MUST process multiple instances consistently with the order specified by `h`. 7.6. Body Canonicalization The `bc` value MUST be either `simple` or `relaxed` as defined by [RFC6376]. The body hash MUST be calculated over the canonicalized message body before SMTP transport-level transformations. MIME content, including attachments, is treated as message body octets. No MIME decoding is performed for the purpose of the VEIF body hash. 7.7. Required Signed Headers The `From` header field MUST be included in `h`. Implementations SHOULD also sign `Date`, `Subject`, `Message-ID`, and `To` where those fields are present. Implementations MAY sign additional fields. Implementations SHOULD avoid signing fields that are routinely modified by legitimate intermediaries unless the deployment explicitly accepts that limitation. 7.8. Binding to the Sender Address The canonicalized `From` header MUST be covered by the VEIF signature. A VEIF verifier MUST verify that the authenticated sender identity represented by the credential is authorized to use the mailbox or sender identity appearing in the signed `From` field. This authorization may be established through credential claims, IdP policy, domain policy, or another VEIF deployment mechanism. A valid cryptographic signature MUST NOT by itself be interpreted as authorization to use an arbitrary email address. 8. Message Signing Procedure A VEIF sender performs the following steps: 1. Obtain a valid VEIF Identity Credential. 2. Ensure that the private key corresponding to the credential's `cnf` claim is available. 3. Construct the email message. 4. Select the message header fields to be signed. 5. Canonicalize the selected headers according to `hc`. 6. Canonicalize the message body according to `bc`. 7. Calculate `hh` and `bh` using SHA-256. 8. Calculate `cred_hash` over the VEIF-Credential value. 9. Construct the VEIF JWS payload. 10. Sign the JWS using the sender private key. 11. Add the VEIF-Credential and VEIF-Signature fields to the message. 12. Transmit the message using normal email transport mechanisms. The sender MUST NOT modify a signed header field or signed body content after generating the VEIF-Signature. 9. Message Verification Procedure A receiving system implementing VEIF SHOULD perform the following steps: 1. Locate the VEIF-Signature field. 2. Locate the corresponding VEIF-Credential field. 3. Parse the JWS Compact Serialization. 4. Verify that the JWS algorithm is permitted by local policy. 5. Parse and validate the SD-JWT VC according to [SD-JWT-VC]. 6. Verify the issuer signature on the SD-JWT VC. 7. Verify that the `vct` value identifies a VEIF Identity Credential. 8. Validate `iss`, `iat`, `nbf`, and `exp` as applicable. 9. Evaluate the credential status information, if present and applicable. 10. Determine whether the issuer is trusted according to local policy. 11. Extract the public key from the credential's `cnf` claim. 12. Verify the VEIF JWS using that public key. 13. Recalculate `cred_hash`. 14. Recalculate `hh` using the header list in `h`. 15. Recalculate `bh` using the specified body canonicalization. 16. Compare the calculated values with `cred_hash`, `hh`, and `bh`. 17. Verify that the signed `From` address is authorized by the credential according to local policy. 18. Produce a VEIF authentication result. A verifier MUST treat the VEIF identity as unverified if any cryptographic, credential, status, authorization, or trust validation required by local policy fails. 10. VEIF Authentication Results 10.1. General VEIF results SHOULD be exposed to mail filtering and user-agent software through the Authentication-Results mechanism defined by [RFC8601]. During the experimental phase, implementations MAY use: Authentication-Results: mx.example; veif=pass The `veif` method is an experimental extension method in this version and is not requested for permanent IANA registration. 10.2. Result Values The following result values are defined for experimental use: pass The VEIF credential and message signature were successfully validated and the sender satisfied local trust and authorization policy. fail VEIF material was present but cryptographic or semantic validation failed. none No VEIF signature was present. temperror A temporary failure prevented validation. permerror The VEIF material was permanently malformed or invalid. policy Cryptographic validation succeeded, but local trust or authorization policy did not accept the issuer or identity. 10.3. Identity Information A receiving system MAY expose additional VEIF information through Authentication-Results. Example: Authentication-Results: mx.example; veif=pass; veif.idp=https://idp.example; veif.assurance=substantial Implementations SHOULD avoid placing personally identifying information in Authentication-Results unless explicitly required by local policy. 11. Trust Model 11.1. No Global Trust Anchor VEIF does not define a single global trust anchor for Identity Providers. A receiving organization MAY determine trusted IdPs through local configuration, organizational trust agreements, contractual accreditation, public key infrastructure, DNSSEC-protected publication, regulatory or sector-specific trust frameworks, or other mechanisms appropriate to the deployment. A credential issued by an unknown IdP MUST NOT automatically be treated as trusted merely because the credential is cryptographically valid. 11.2. Issuer Key Discovery SD-JWT VC issuer key discovery and validation MUST follow the applicable SD-JWT VC rules and local policy. VEIF does not define a second independent issuer-key format. 11.3. Domain Authorization A VEIF credential MUST NOT override domain-level authorization policy. In deployments requiring domain authentication, receivers SHOULD validate SPF, DKIM, and/or DMARC independently. 11.4. Multiple Identity Providers A sender MAY hold credentials issued by more than one IdP. Receivers MAY apply different trust policies to different IdPs. The existence of multiple credentials MUST NOT be interpreted as evidence that the underlying identities are identical. 12. Credential Status and Revocation A VEIF verifier MUST determine whether a credential is still valid according to the status mechanism required by the applicable SD-JWT VC deployment. VEIF does not define a new OCSP-like or CRL-like protocol. Deployments SHOULD use the status mechanisms defined by the SD-JWT VC ecosystem. The Token Status List specification [I-D.ietf-oauth-status-list] is one such mechanism under active IETF development and defines status information for tokens including SD-JWT and SD-JWT VC. Deployments MAY use short-lived credentials to reduce dependence on online revocation checks. If a sender private key is compromised, the associated credential MUST be revoked, suspended, replaced, or otherwise rendered unacceptable according to the IdP's policy. 13. Privacy Considerations 13.1. No Mandatory Public Identity VEIF does not require disclosure of the sender's civil identity to the recipient. A receiver can establish that: o a credential was issued by an IdP; o the credential identifies a sender identity; o the credential is associated with a verified entity according to the IdP's policy; o the sender controls the corresponding cryptographic key; and o the message was signed by that key. The receiver need not learn the name, address, national identifier, or other civil identity information of the Verified Entity. 13.2. Pseudonymous Subjects The `sub` value SHOULD be pseudonymous. IdPs SHOULD avoid globally stable identifiers when they are not necessary for accountability. Pairwise or deployment-specific subject identifiers MAY be used. Care must be taken because even pseudonymous identifiers can create correlation risks if they are reused across unrelated recipients. 13.3. Accountability Without Disclosure Accountability is provided through the IdP's retained mapping between the credential and the Verified Entity. VEIF does not require an online identity lookup for every received message. A receiving system SHOULD NOT contact the IdP merely to discover the sender's civil identity. Where identification is necessary, the IdP MAY disclose the corresponding identity only under its applicable policy and lawful or otherwise authorized process. 13.4. Data Minimization IdPs SHOULD minimize the personal information contained in credentials. Message signatures SHOULD contain only information required to establish the message binding. VEIF-Signature MUST NOT require inclusion of a person's name, national identity number, physical address, or equivalent personal information. 13.5. Header and Credential Leakage VEIF-Credential is part of the email message and can be stored, indexed, logged, forwarded, archived, or exposed to intermediaries. A VEIF deployment MUST therefore assume that all information carried in VEIF-Credential may become visible to entities that can inspect the message. Sensitive identity claims SHOULD be selectively disclosable and SHOULD NOT be placed in the credential as cleartext unless their disclosure is intentional. 14. Security Considerations 14.1. Identity Misbinding The principal security risk is incorrect association between an email address and a Verified Entity. IdPs MUST establish both the identity of the entity and the entity's authorization to use the sender identity. A cryptographically valid credential issued after inadequate identity verification does not provide meaningful accountability. 14.2. Compromised Credentials If an attacker obtains the private sender key, the attacker can create valid VEIF signatures until the credential is revoked, expires, or otherwise becomes unacceptable. Deployments SHOULD use hardware-backed or otherwise protected key storage where appropriate. 14.3. Compromised Identity Provider A compromised or malicious IdP could issue credentials to false identities. Receiver policy therefore remains essential. High-assurance deployments SHOULD restrict trusted IdPs to organizations subject to suitable security and identity-verification requirements. 14.4. Replay VEIF message signatures do not by themselves prevent a valid signed message from being copied and retransmitted. A verifier MAY detect duplicate use of a signature, credential `jti`, or Message-ID. VEIF does not require global replay detection because ordinary email forwarding and retransmission make global replay semantics difficult to define. 14.5. Message Modification Modification of a signed header or body region causes the VEIF message signature to fail. As with DKIM, the choice between `simple` and `relaxed` canonicalization affects the degree of tolerance to legitimate message transformation. 14.6. Header Injection Implementations MUST correctly parse Internet Message Format and MUST perform header unfolding before semantic processing. Implementations MUST NOT permit untrusted input to alter the logical interpretation of the VEIF-Signature or VEIF-Credential fields. 14.7. Algorithm Agility VEIF implementations MUST support algorithm agility. During the experimental phase ES256 is mandatory to implement. Other algorithms MAY be supported according to the JOSE registries and local policy. The use of `none` as a JWS algorithm is prohibited. 14.8. Sender Identity Versus Human Actor VEIF does not prove that a particular human physically operated the keyboard that caused a message to be sent. It establishes a chain from the message to a cryptographic key and from that key to a credential and Verified Entity. Investigations MUST distinguish between the Verified Entity, the account holder, an authorized agent, an automated sending system, a compromised account, and the individual human who actually generated a particular message. 14.9. Denial of Service Verifiers SHOULD place resource limits on SD-JWT VC size, number of disclosures, cryptographic operations, status retrieval, issuer key retrieval, and header field size. VEIF validation SHOULD NOT permit an unauthenticated sender to cause excessive external requests to an IdP or status provider. 14.10. Trust Downgrade An implementation MUST NOT silently interpret an unverified or unknown VEIF identity as equivalent to a verified VEIF identity. In particular, absence of VEIF MUST NOT be represented as a successful VEIF result. 15. Forwarding and Intermediaries VEIF message signatures are end-to-end message signatures. An intermediary that modifies a signed header or the signed body can invalidate the signature. VEIF does not attempt to solve all forwarding and message transformation problems addressed by mechanisms such as ARC [RFC8617]. A deployment MAY use VEIF together with ARC when messages are processed by intermediaries. A future version of VEIF MAY define explicit interactions with ARC, mailing lists, forwarding services, and other message-transforming systems. 16. Relationship to Credential Standards 16.1. SD-JWT VC VEIF deliberately uses SD-JWT VC rather than defining a proprietary identity assertion format. This provides compatibility with the SD-JWT ecosystem and avoids defining another general-purpose credential serialization. VEIF is therefore a profile of SD-JWT VC rather than an alternative credential format. 16.2. SD-JWT Key Binding SD-JWT VC supports cryptographic key binding through the `cnf` claim. The normal SD-JWT+KB presentation mechanism can use an audience and nonce associated with a presentation transaction. Ordinary email is generally asynchronous and unsolicited and does not necessarily provide an interactive verifier challenge. Therefore, VEIF uses the `cnf` key binding of the credential but defines an email-specific message-binding signature rather than requiring a conventional nonce-based Key Binding JWT exchange. This is a VEIF application profile decision. It does not redefine SD-JWT or SD-JWT VC. 16.3. W3C Verifiable Credentials The conceptual model of VEIF is compatible with the general issuer, holder, and verifier model used by the W3C Verifiable Credentials Data Model [VC-DATA-MODEL]. VEIF does not define the W3C Verifiable Credentials Data Model as its wire format. The wire-level VEIF credential format is SD-JWT VC. Implementations MAY map VEIF identity information to a W3C Verifiable Credential representation where required by an application ecosystem. 17. Deployment Model 17.1. Incremental Deployment VEIF is intended to be incrementally deployable. A sending organization can deploy VEIF without changing ordinary SMTP transport. A receiving organization can initially use VEIF only for scoring, display, filtering, or investigation. Later, a receiver MAY adopt policies such as preferring VEIF-authenticated messages, displaying a verified-sender indicator, applying stronger anti-phishing policies to non-VEIF messages, or requiring VEIF for selected high-risk communication channels. 17.2. No Requirement for Universal Adoption VEIF MUST NOT require every Internet email address to be VEIF enabled. Non-VEIF mail remains valid email. Whether non-VEIF mail is accepted, filtered, quarantined, or rejected is a local policy decision. 17.3. High-Assurance Applications VEIF may be particularly useful for financial institutions, government communications, healthcare organizations, legal communications, corporate communication, customer-service systems, transactional email, critical infrastructure, and other environments in which sender accountability is valuable. 18. Example Consider a sender using: alice@example.com The Identity Provider verifies Alice according to its assurance policy and issues an SD-JWT VC containing, conceptually: { "vct":"urn:uuid:4c4f4663-6d52-4f2b-a987-8cb17fb10019", "iss":"https://idp.example", "sub":"pairwise-opaque-subject", "jti":"credential-instance-id", "cnf":{ "jwk":{ "kty":"EC", "crv":"P-256", "x":"...", "y":"..." } }, "iat":1791378000, "exp":1822914000, "veif_assurance":"substantial" } The actual credential is signed by the IdP. The sender then signs an email using the private key corresponding to the `cnf` public key. The message contains: VEIF-Credential: eyJ0eXAiOiJkYytzZC1qd3QiLCJhbGciOiJFUzI1NiJ9... VEIF-Signature: eyJhbGciOiJFUzI1NiIsInR5cCI6InZlaWYrandzIn0... The receiver validates the SD-JWT VC, validates the issuer, checks credential status and validity, extracts the public key from `cnf`, verifies the VEIF-Signature, verifies the signed `From` address and message hashes, and applies its trust policy to the IdP. The receiver may then record: veif=pass The recipient does not need to learn Alice's real-world identity. If the message is subsequently associated with fraud or other abuse, an authorized investigator can identify the credential and contact the issuing IdP according to the applicable process. 19. Example Authentication Results A receiving MTA may produce: Authentication-Results: mx.example; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com; veif=pass The exact presentation of ancillary VEIF information is a local policy matter during the experimental phase. A receiving system MUST NOT expose the sender's civil identity merely because it has generated a `veif=pass` result. 20. IANA Considerations 20.1. VEIF-Signature Header This document requests provisional registration of the following message header field in the IANA "Provisional Message Header Field Names" registry, following the registration procedures in [RFC3864]: Header field name: VEIF-Signature Applicable protocol: mail Status: provisional Author/Change controller: Seppo Uimonen , Independent Specification document(s): draft-uimonen-veif Related information: none 20.2. VEIF-Credential Header This document requests provisional registration of: Header field name: VEIF-Credential Applicable protocol: mail Status: provisional Author/Change controller: Seppo Uimonen , Independent Specification document(s): draft-uimonen-veif Related information: none Registration of these header fields does not imply endorsement by the IETF, IANA, or any other organization. 20.3. Authentication-Results This document does not request permanent registration of `veif` in the IANA Email Authentication Methods registry. The `veif` authentication method is experimental in this version. Implementations MAY use it as an extension authentication method as permitted by [RFC8601]. A future revision may request IANA registration after the protocol semantics and interoperability experience have stabilized. 20.4. Credential Type Identifier The VEIF credential type identifier used by this document is the UUID URN defined in Section 5.2. No IANA registration of that UUID is requested by this document. 21. Implementation Considerations Implementers are encouraged to build interoperable prototypes before attempting production deployment. At minimum, an experimental implementation should support: o SD-JWT VC validation; o ES256; o `cnf`-based sender key binding; o VEIF-Signature; o VEIF-Credential; o DKIM `simple` and `relaxed` canonicalization; o SHA-256; o credential expiry validation; o credential status validation where supported; o issuer trust policy; and o Authentication-Results reporting. Implementations SHOULD provide diagnostic information explaining why VEIF validation failed. Suggested diagnostic categories include: o missing-credential; o malformed-credential; o unknown-issuer; o invalid-issuer-signature; o expired-credential; o revoked-credential; o invalid-key-binding; o invalid-message-signature; o header-hash-mismatch; o body-hash-mismatch; o unauthorized-from-address; and o policy-failure. 22. Open Issues for Further Work The following topics are intentionally left open for discussion and experimentation: o interoperable identity assurance levels; o interoperable IdP trust discovery; o domain-to-IdP authorization; o alternative credential retrieval mechanisms; o interaction with ARC; o mailing-list processing; o delegated sending; o automated agents; o hardware-backed sender keys; o status and revocation policy; o pairwise subject identifiers; o legal and regulatory interoperability; o standardized Authentication-Results registration; and o interoperability with other accountable sender identity systems. These issues are deliberately not solved by introducing additional proprietary cryptographic formats in this version. 23. Design Principle The central design principle of VEIF is separation of authentication, verification, and accountability. A recipient should not have to choose between completely anonymous email and globally public disclosure of the sender's civil identity. VEIF instead provides an intermediate model: cryptographically authenticated + identity-provider verified + privately accountable This model is intended to preserve ordinary email privacy while making large-scale identity abuse more difficult and making subsequent investigation technically more effective. VEIF does not claim that accountability alone will eliminate spam, phishing, fraud, or abuse. Its purpose is to add an identity and accountability signal that existing domain-level email authentication mechanisms do not provide. 24. References 24.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008. [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, DOI 10.17487/RFC6376, September 2011. [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015. [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015. [RFC7800] Jones, M., "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019. [RFC9901] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, November 2025. [SD-JWT-VC] Terbu, O., Fett, D., and B. Campbell, "SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)", Work in Progress, Internet-Draft draft-ietf-oauth-sd-jwt-vc-19, August 2026. 24.2. Informative References [RFC8617] Kucherawy, M., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004. [I-D.ietf-oauth-status-list] Looker, T., Bastian, P., and C. Bormann, "Token Status List (TSL)", Work in Progress, Internet-Draft draft-ietf-oauth-status-list-21, June 2026. [VC-DATA-MODEL] Reed, D., Sporny, M., Longley, D., Allen, C., Grant, R., and M. Sabadello, "Verifiable Credentials Data Model v2.0", W3C Recommendation, 15 May 2025. 25. Acknowledgements The author thanks the IETF community and the authors of the email authentication, JWT, selective disclosure, and verifiable digital credential specifications on which this experimental work builds. Author's Address Seppo Uimonen Independent Finland Email: me@seppo-uimonen.fi