Network Working Group L. Johansson Internet-Draft SIROS Foundation Intended status: Informational B. Zundel Expires: 6 May 2027 Yubico T. Cappalli Okta H. Birkholz Fraunhofer SIT 2 November 2026 A Reference Architecture for Verifiable Digital Credentials in the Issuer, Holder, Verifier Model draft-ietf-spice-vdcarch-02 Abstract This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. 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 6 May 2027. Johansson, et al. Expires 6 May 2027 [Page 1] Internet-Draft Architecture for Verifiable Digital Cred November 2026 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Actor Descriptions . . . . . . . . . . . . . . . . . . . 5 5.1.1. Presentation Mediator (Credential Presentation User Agent) . . . . . . . . . . . . . . . . . . . . . . . 5 5.1.2. Credential Store . . . . . . . . . . . . . . . . . . 6 5.1.3. Issuer and Verifier . . . . . . . . . . . . . . . . . 6 5.2. Behavioral Constraints . . . . . . . . . . . . . . . . . 6 5.2.1. Holder Control . . . . . . . . . . . . . . . . . . . 6 5.2.2. Issuer Binding . . . . . . . . . . . . . . . . . . . 6 5.2.3. Mediator Binding . . . . . . . . . . . . . . . . . . 7 5.2.4. Selective Disclosure . . . . . . . . . . . . . . . . 7 5.2.5. Non-linkability and data minimization . . . . . . . . 7 5.2.6. Revocation . . . . . . . . . . . . . . . . . . . . . 7 5.3. Relationships . . . . . . . . . . . . . . . . . . . . . . 7 5.3.1. Credentials and Presentation Proofs . . . . . . . . . 8 5.3.2. Subject and Holder . . . . . . . . . . . . . . . . . 8 6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. General Flows . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Direct Presentation Flow . . . . . . . . . . . . . . . . 8 7.2. Additional Flows . . . . . . . . . . . . . . . . . . . . 10 8. Security and Privacy Considerations . . . . . . . . . . . . . 11 8.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Johansson, et al. Expires 6 May 2027 [Page 2] Internet-Draft Architecture for Verifiable Digital Cred November 2026 Document History . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "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. 2. Introduction Verifiable digital credentials, which assert claims about individuals, organizations, or devices, have become essential tools in modern identity systems. Whether verifying an individual's qualifications, attesting to an enterprise's compliance, or authorizing an IoT device, these credentials rely on secure, efficient, and privacy-preserving mechanisms for their use. Traditional federated identity systems often rely on intermediaries or delegation, which can compromise user privacy or introduce inefficiencies. This document presents an architecture for direct presentation flows, where credentials are presented directly to verifiers without unnecessary intermediaries, empowering the credential subject or their authorized representative to maintain control over the credential's use. At the heart of this architecture is the presentation mediator, an active software component responsible for facilitating secure and privacy-aware interactions. This mediator works in tandem with passive credential stores, verifiers, and issuers, creating a scalable and interoperable system that can adapt to diverse regulatory and operational environments. 3. Use Cases 4. Terminology Credential Manager: An application, hardware device, or service which securely stores, organizes, manages, and enables presentation of credentials. Digital wallets, password managers, and passkeys managers are examples of Credential Managers. Credential Store: A passive repository for securely storing credentials. It supports the presentation mediator by providing access to stored credentials without performing active operations. Johansson, et al. Expires 6 May 2027 [Page 3] Internet-Draft Architecture for Verifiable Digital Cred November 2026 Credential Subject: The entity the credential pertains to, such as an individual, organization, or object. Holder: TBD Issuance: The process of cryptographically signing a Verifiable Digital Credential, and delivering it to a holder's Credential Manager Issuance Protocol: An application-layer protocol used between an Issuer and Credential Manager to issue a Verifiable Digital Credential. Issuer: The entity that cryptographically signs a verifiable digital credential, thereby asserting its claims about a subject. Issuer Service: The underlying platform or infrastructure service which enables an Issuer to issue a Verifiable Digital Credential to a Holder's Credential Manager. Local Device: The physical device hosting the user agent or application which interacts with an Issuer or Verifier, and exposes and/or invokes a Mediation API. Mediation API: An interface which brokers communication between a calling application and a Credential Manager, without exposing the underlying credential storage, keys, or transport bindings directly to the caller. These interfaces are typically provided by operating systems and user agents. Nearby Device: A distinct physical device in physical proximity to the Local Device, which hosts a Credential Manager, and is accessed via a Mediation API. Presentation: TBD Presentation Mediator: a software user agent that manages the presentation of credentials to the verifier on behalf of the holder. It is responsible for initiating and mediating credential presentations, ensuring compliance with holder preferences and system policies. The holder controls a presentation mediator. Presentation Proof: Proof to a Verifier that a particular issuer has provided a Verifiable Digital Credential to the Presentation Mediator. A Presentation Proof is a derived artifact that proves claims from a credential in a specific interaction with a Verifier. Johansson, et al. Expires 6 May 2027 [Page 4] Internet-Draft Architecture for Verifiable Digital Cred November 2026 Presentation Protocol: An application-layer protocol used between a Verifier and a Credential Manager to request claims from one or more Verifiable Digital Credentials. Holder: The actor that receives a credential from an issuer and delivers a presentation to a verifier. While often the credential subject, the holder could also be a party authorized to present claims about the subject. Verifiable Digital Credential (VDC): A cryptographically verifiable, tamper-evident assertion of claims about a subject, signed by an Issuer. VDCs are issued to a Holder, stored in a Credential Manager, and presented to a Verifier. Verifier: The entity that cryptographically validates the authenticity and integrity of a Verifiable Digital Credential. A Verifier is typically, but not always, the relying party. Verifier Service: The underlying platform or infrastructure service which enables a Verifier to validate a Verifiable Digital Credential. 5. Architecture 5.1. Actor Descriptions 5.1.1. Presentation Mediator (Credential Presentation User Agent) The presentation mediator is the core active component of this architecture. It is a user agent that initiates and mediates credential presentations, ensuring compliance with holder preferences and system policies. For example, it might enforce selective disclosure, revealing only the subject's date of birth to a verifier while withholding other personal details. Often the holder and subject are one and the same entity, e.g., a natural person controlling her own credentials. However, there are several situations where the holder and subject are different entities. For instance, cases where presentation is delegated from a legal entity to an officer of a company or when care staff helps somebody with disabilities present personal credentials. Unlike a credential store, the presentation mediator is responsible for orchestrating interactions with verifiers, performing cryptographic operations, and generating presentation proofs. Johansson, et al. Expires 6 May 2027 [Page 5] Internet-Draft Architecture for Verifiable Digital Cred November 2026 The mediator is used by the holder to communicate with issuers verifiers. The nature of the control the holder has over the mediator varies but minimally the holder must be able to initiate the receipt of credentials from an issuer the generation and transmission of presentation proofs to a verifier. The mediator acts on behalf of the holder when receiving credentials from an issuer and the issuance process typically involves authenticating the holder to the issuer. 5.1.2. Credential Store The credential store is a passive repository where credentials are securely stored. Its primary function is to provide the presentation mediator with access to the credentials it needs to generate presentation proofs. By separating storage from active mediation, the architecture enhances modularity and allows credential stores to be managed independently from presentation logic. 5.1.3. Issuer and Verifier An issuer is a set of protocol endpoints that allow a mediator to receive a credential. Credentials issued by the issuer are cryptographically bound to that issuer and to the receiving mediator. A verifier is a set of protocol endpoints that allow a mediator to send a presentation to a verifier. A verifier is typically a component used to provide an application with data about the subject - for instance in the context of an authentication process. 5.2. Behavioral Constraints TBD - more constraints 5.2.1. Holder Control The mediator SHOULD provide the holder with the means to control which data from a credential is used in a presentation proof. The mediator MUST NOT be able to generate a presentation proof without the participation and approval of the credential holder. 5.2.2. Issuer Binding A verifier MUST be able to verify the identity of the issuer of the credential from a presentation proof. Johansson, et al. Expires 6 May 2027 [Page 6] Internet-Draft Architecture for Verifiable Digital Cred November 2026 5.2.3. Mediator Binding The verifier MUST be able to verify that the mediator sending the presentation proof is the same mediator that received the credential from which the presentation proof was derived. Note that this is often termed 'holder' binding because the mediator is a user agent for the holder. 5.2.4. Selective Disclosure A conformant implementation SHOULD identify a format for representing digital credentials that make it possible for the holder to select a subset of the claims in the credential for inclusion in a presentation proof. Note: there are situations where selective disclosure isn't applicable, for instance when the holder is legally compelled to present a credential. Exactly when selective disclosure is available as an option and what aspects of the credential are meaningful to select is an implementation issue and out of scope. 5.2.5. Non-linkability and data minimization The verifier MUST NOT be able to infer information about data or subjects not present in the presentation. This includes any association between the mediator or subject and other issuers and verifiers not associated with the presentation. In particular, colluding verifiers MUST NOT be able to infer data not present in presentation proofs. 5.2.6. Revocation A conformant implementation SHOULD provide a way for an issuer to revoke an issued digital credential in such a way that subsequent attempts by a verifier to verify the authenticity of proofs based on that credential fail. 5.3. Relationships TBD - more (and better?) relationships Johansson, et al. Expires 6 May 2027 [Page 7] Internet-Draft Architecture for Verifiable Digital Cred November 2026 5.3.1. Credentials and Presentation Proofs A verifiable digital credential is an object representing a set of claims associated with a subject. The credential MAY contain claims that uniquely identify a single subject. A verifiable digital credential is typically cryptographically bound both to the issuer and to the mediator to which it is issued. A presentation proof can be: 1. Based on data present in a single credential. 1. Based on data present in multiple credentials. 1. Based on the result of computations made on a set of credentials. One example is a presentation proof that a subject is legally permitted to take driving lessons. This is a binary attribute which is the result of a computation involving knowledge of both the biological age of the subject as well as legal restrictions that apply to the jurisdiction where the verifier is operating. 5.3.2. Subject and Holder The credential subject is the entity that the credential describes, such as an individual, an organization, or even an IoT device. However, the holder—the actor delivering the credential to the verifier—may not always be the credential subject. For example, an administrator might present credentials on behalf of an organization, or a customs broker might act as a holder for a credential about goods in a shopment. This distinction between the credential subject and the holder allows the architecture to support complex use cases, such as power-of- attorney scenarios or enterprise credentialing systems. 6. Trust Model TBD 7. General Flows Credential presentation flows describe how information from credentials are transmitted from the mediator to the verifier. This architecture focuses on direct presentation flows, but it also accommodates variations such as delegated and assisted presentations. 7.1. Direct Presentation Flow Johansson, et al. Expires 6 May 2027 [Page 8] Internet-Draft Architecture for Verifiable Digital Cred November 2026 +------+ +--------+ +------+ +--------+ |Holder| |Mediator| |Issuer| |Verifier| +---+--+ +----+---+ +---+--+ +----+---+ | | | | +----+-----+--------------+--------------------+--------------+--+ | ISSUANCE | | | | | +----+-----+ | | | | | | | | | | | +------------------->| request | | | | | initiate | credential | | | | | credential +------------------->| generate | | | | request | | credential | | | | | +------+ | | | | | | | | | | | | |<-----+ | | | | | | | | | | | credential | | | | | |<-------------------+ | | +----+--------------------+--------------------+--------------+--+ | | | | | | | | +----+---------+----------+--------------------+--------------+--+ | VERIFICATION | | | | | +----+---------+ | | request | | | | | | presentation | | | | prompt to select |<----------------------------------+ | | | credential(s) | | | | | |<-------------------+ | | | | | select claims from | | | | | | credential(s) | | | | | +------------------->| | | | | | | generate | | | | | +-----+ presentation | | | | | | | proof | | | | | |<----+ selection | | | | | | | presentation | | | | | | proof | | | | +---------------------------------->| | +----|--------------------+--------------------+--------------+--+ | | | | +---+--+ +----+---+ +---+--+ +----+---+ |Holder| |Mediator| |Issuer| |Verifier| +------+ +--------+ +------+ +--------+ Figure 1: Basic Verifiable Cigital Credential Flow Johansson, et al. Expires 6 May 2027 [Page 9] Internet-Draft Architecture for Verifiable Digital Cred November 2026 The mediator (acting on behalf of the subject) requests a credential from the issuer. The way this flow is initiated is implementation dependent and in some cases (notably in [OIDC4VCI]) the flow often starts with the subject visiting a web page at the issuer where the subject is first authenticated and then presented with means to launch a credential issuance request using their mediator. These details are left out from the diagram above. The credential is generated by the issuer presumably based on information the issuer has about the credential subject but exactly how the credential is generated is implementation dependent and out of scope for this specification. The claims in the credential typically comes from some source with which the issuer has a trust relationship. The term "authentic source" is sometimes used when there is a need to distinguish the source of the claims in a credential from the source of the credential which by definition is the issuer. The mediator receives a credential from the issuer. The credential is bound both to the mediator and to the issuer in such a way that presentation proofs generated from the credential can be used to verify said bindings. At some later point, the subject wants to use the credentials in their mediator to provide identity data to an application. The application has a verifier (a specific software component responsible for verifying presentation proofs) associated with it. The mediator - often after involving the user in some form of interaction to choose which credential(s) to use and what parts of the credential(s) to include - generates a presentation proof and sends it to the verifier. The precise way this flow is initiated is again implementation dependent and in some cases (notably [OIDC4VP]) the flow starts with the subject visiting the application and hitting a "login" button which directs the users device to launch the mediator to complete the flow. These details are left out of the diagram above. Upon receipt of the presentation the verifier verifies the issuer and mediator binding (aka holder binding) of the proof and - if the implementation supports revocation - the current validity of the underlying credential(s). If successful the data in the proof is made available to the application. 7.2. Additional Flows TBD Johansson, et al. Expires 6 May 2027 [Page 10] Internet-Draft Architecture for Verifiable Digital Cred November 2026 8. Security and Privacy Considerations ## Security One of the main security considerations of a direct presentation credential architecture is how to establish the transactional trust between both the entities (mediators, issuers and verifiers) as well as the technical trust necessary for the cryptographic binding between the digital credentials and their associated presentation. Digital credentials are sometimes long-lived which also raises the issue of revocation with its associated security requirements. 8.1. Privacy TBD 9. IANA Considerations This document has no IANA considerations. 10. Appendix ## Examples of Components ## Exploration of Standardization Gaps 11. References 11.1. Normative References [BSL] Sporny, M., Longley, D., Prorock, M., and M. Alkhraishi, "Bitstring Status List v1.0", n.d., . [CID] Sporny, M. and M. B. Jones, "Controlled Identifiers v1.0", n.d., . [DID] Sporny, M., Guy, A., Sabadello, M., and D. Reed, "Decentralized Identifiers (DIDs) v1.0", n.d., . [OIDC4VCI] Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for Verifiable Credential Issuance", n.d., . [OIDC4VP] Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. Looker, "OpenID for Verifiable Presentations", n.d., . Johansson, et al. Expires 6 May 2027 [Page 11] Internet-Draft Architecture for Verifiable Digital Cred November 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SDJWT] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet- Draft, draft-ietf-oauth-selective-disclosure-jwt-22, 29 May 2025, . [VCDM2] Sporny, M., Thibodeau, T., Herman, I., Cohen, C., and M. B. Jones, "Verifiable Credentials Data Model v2.0", n.d., . [VCJOSE] Prorock, M., Cohen, C., and M. B. Jones, "Securing Verifiable Credentials using JOSE and COSE", n.d., . 11.2. Informative References [ARF] COM, "The European Digital identity Wallet architecture and Reference framework", n.d., . [DIDKEY] Longley, D., Zagidulin, D., and M. Sporny, "The did:key Method v0.7", n.d., . [OPENIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", 2014. [PathToSSI] Allen, C., "The Path to Self-Sovereign Identity", n.d., . [SAML] Hallam-Baker, P. and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)", OASIS Committee Specification sstc-core, 31 May 2002, . Johansson, et al. Expires 6 May 2027 [Page 12] Internet-Draft Architecture for Verifiable Digital Cred November 2026 [TSL] Looker, T., Bastian, P., and C. Bohrmann, "Token Status List", n.d., . Acknowledgments Several people have contributed to this text through discussion. The authors especially wish to acknowledge the following individuals who have helped shape the thinking around trust and identity in general and this topic in particular. * Pamela Dingle * Heather Flanagan * Peter Altman * Giuseppe DeMarco * Lucy Lynch * R.L. 'Bob' Morgan * Jeff Hodges * Rohan Mahy Document History -02 * Changed the Title * Coverted ASCII diagram to AASVG * Revised the page header * Add Henk Birkholz as an author * Substantial restructuring of the document: - Created entirely new layout and moved existing text - Consolidated and revised terminology - Alphabetized terminology - Added TBDs Johansson, et al. Expires 6 May 2027 [Page 13] Internet-Draft Architecture for Verifiable Digital Cred November 2026 - fixed line lengths * Updated terminology, capitalized official terms * changed presenter -> holder * significantly revised the diagram for simplicity and space * Added document history -01 * Initial working group draft, based on draft-zundel-vdcarch-00 -00 * Draft that got created when someone accidentally hit the wrong button even though it hadn't been adopted yet Authors' Addresses Leif Johansson SIROS Foundation Sweden Email: leifj@siros.org Brent W. Zundel Yubico United States Email: brent.zundel@gmail.com Tim Cappalli Okta United States Email: timcappalli@cloudauth.dev Henk Birkholz Fraunhofer SIT Germany Email: henk.birkholz@ietf.contact Johansson, et al. Expires 6 May 2027 [Page 14]