| Internet-Draft | Use Cases for SPICE | March 2025 |
| Prorock & Zundel | Expires 18 September 2025 | [Page] |
This document describes various use cases related to credential exchange in a three party model (issuer, holder, verifier). These use cases aid in the identification of which Secure Patterns for Internet CrEdentials (SPICE) are most in need of specification or detailed documentation.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://brentzundel.github.io/draft-ietf-spice-use-cases/draft-ietf-spice-use-cases.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-spice-use-cases/.¶
Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (mailto:spice@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spice/. Subscribe at https://www.ietf.org/mailman/listinfo/spice/.¶
Source for this draft and an issue tracker can be found at https://github.com/brentzundel/draft-ietf-spice-use-cases.¶
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 18 September 2025.¶
Copyright (c) 2025 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.¶
There is a need to more clearly document digital credentials that utilize the issuer-holder-verifier model across various work at IETF, ISO, W3C, and other SDOs. This need particularly arises in use cases for verifiable credentials that do not involve human-in-the-loop interactions, require strong identifiers for business entities, call for the benefits of CBOR encoding, or leverage the cryptographic agility properties of COSE. This document covers multiple use cases for verifiable credentials that help inform both the required architecture and components, as well as to frame needs for clearly defined message formats or supporting mechanisms.¶
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.¶
Within SPICE there are a few common patterns that continually arise:¶
Selective disclosure with CBOR based verifiable credentials¶
Cryptographic agility support via COSE, including support for PQC, and to permit use of the same signature algorithms with both selective disclosure as well as fully disclosed credentials¶
Strong and long-lived identities that may be correlated with public key material for verification and permit binding to DNS or existing x509 certificates, as well as providing ready access to public keys for verification utilizing HTTP¶
There are several expanding use cases and common patterns that motivate the working group and broader community, including:¶
Microcredentials, particularly in education¶
Digitization of physical supply chain documents in multiple jurisdictions:¶
Credentials related to IoT, Control Systems, and Critical Infrastructure¶
Credentials related to authenticity and provenance, especially of digital media¶
Offline exchange (in person) of credentials that may have been internet issued¶
Embedding credentials in other data formats¶
Digital Wallet Initiatives¶
An "issuer", an entity (person, device, organization, or software agent) that constructs, secures, and shares digital credentials.¶
A "holder", an entity (person, device, organization, or software agent) that stores issued credentials and controls their disclosure.¶
A "verifier", an entity (person, device, organization, or software agent) that receives, verifies, and validates disclosed digital credentials.¶
Microcredentials provide a flexible and verifiable way to recognize skills, achievements, and competencies in education. Unlike traditional degrees or certifications, microcredentials offer a modular and portable format that can be tailored to specific learning outcomes. They enable lifelong learning, career advancement, and industry-aligned skill validation while allowing learners to demonstrate their achievements in a verifiable and interoperable manner.¶
Common use cases:¶
Microcredentials for industry-specific skills such as cloud computing, cybersecurity, or data analytics, enabling verifiable skills on job applications, LinkedIn profiles, or digital resumes.¶
Recognizing individual competencies as learners progress through a program, which allows institutions and employers to verify achievements more granularly.¶
Stackable microcredentials that allow learners to accumulate and combine microcredentials into a larger qualification.¶
Work-integrated learning and apprenticeships: skills and competencies gained through internships, apprenticeships, or on-the-job training, enabling employers to issue digital credentials for workplace learning experiences.¶
Recognition of informal learning, community-based education, or non-degree programs to support individuals without access to traditional higher education.¶
Physical supply chains provide several unique scenarios and requirements for implementers of digital credentials. There is a strong movement toward digitization of physical supply chain documents which are typically exchanged on paper or scanned pdf form today using legacy approaches. Some steps have been taken towards digitatization of supply chain documents using XML, however this has proved problematic over native binary formats due to the complexity, size, and volumes of transmission often involved.¶
Common use cases for physical supply chains include:¶
Regulatory data capture and exchange with governmental bodies¶
Requirements around capturing specific types of data including:¶
Providing the ability for 3rd parties to "certify" information about another actor in the supply chain. e.g., Vendor A is an approved supplier for Company X¶
Passing of data between multiple intermediaries, before being sent along to customs agencies or consignees.¶
Moving large amounts of signed data asyncronously, and bi-directionally over a network channel¶
Identifying actors in a supply chain and linking them with legal entity information¶
The deployment of digital credentials in constrained systems such as IoT, control systems, and critical infrastructure environments introduces challenges. These systems often operate in environments with strict security, latency, and interoperability requirements. Digital credentials play a role in ensuring secure device identity, access control, and trusted data exchange between interconnected systems.¶
Common use cases include: - Device identity and authentication ensuring only authorized IoT devices can connect to a network or control system. - Restricting access to critical systems, such as industrial control systems, SCADA networks, and energy grid controllers, to only authorized personnel and devices. - Role-based access control (RBAC) and attribute-based access control (ABAC) policies using digital credentials. - Encrypted and authenticated data exchange between industrial sensors, actuators, and control systems. - Verifying software updates and firmware integrity using signed credentials to prevent unauthorized modifications. - Tamper-resistant logging and auditing: digitally signed operational logs and sensor data to enable post-incident forensic analysis. - Temporary access credentials for emergency personnel and automated response systems during critical incidents.¶
Many real-world scenarios require credentials to be disclosed, verified, and validated without continuous or immediate access to online services. This can be due to network limitations, privacy concerns, or operational constraints in environments where connectivity is intermittent or unavailable. Some digital credential frameworks assume online verification mechanisms, which may not be suitable for offline-first environments where entities must verify credentials using locally-available data and cryptographic techniques.¶
Common use cases include:¶
Identity verification in disconnected environments, such as remote regions, military operations, or disaster recovery efforts.¶
Travel and border security, where credentials such as visas, vaccination records, or national IDs must be verified in locations with limited or no network connectivity.¶
Access control in secure facilities, such as industrial sites, research labs, or private events.¶
Device authentication in air-gapped systems.¶
Peer-to-peer credential sharing.¶
TODO embedding credentials use case¶
TODO digital wallet use case¶
TODO Security¶
This document has no IANA actions.¶
TODO acknowledge.¶