Internet-Draft sd-cwt March 2024
Prorock & Zundel Expires 4 September 2024 [Page]
Intended Status:
M. Prorock
B. Zundel
Gen Digital

Use Cases for SPICE


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.

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

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 4 September 2024.

Table of Contents

1. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Introduction

There is a need to more clearly document verifiable credentials - that is credentials that utilize the issuer, holder, and verifier (three party) model across various work 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, need strong identifiers for business entities, and for those that require CBOR encoding, and those that leverage the cryptographic agility properties of COSE. This document which covers multiple use cases for verifiable credentials will help inform both the required architecture and components, as well as to help frame needs for any clearly defined message formats and/or supporting mechanisms.

3. SPICE Common Patterns

Within SPICE there are a few common patterns that continually arise:

4. SPICE Use Cases

There are several expanding use cases and common patterns that motivate the working group and broader community, including:

5. Use Case Discussion

5.1. Roles

An "issuer", an entity (person, device, organization, or software agent) that constructs and secures digital credentials.

A "holder", an entity (person, device, organization, or software agent) that controls the disclosure of credentials.

A "verifier", an entity (person, device, organization, or software agent) that verifies and validates secured digital credentials.

5.2. Physical Supply Chain Credentials

Physical supply chain credentials create several unique scenarios and requirements for technical implementers. There is a strong movement towards digitiztion of physical supply chain data which is often exchanged in paper or scanned pdf form today using legacy approaches. Some steps have been taken towards digitatization of supply chain data in XML, however the steps have 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:

    • Inspection information
    • Permits
    • Compliance certification (both regulatory and private)
    • Traceability information, including change of control and geospatial coordinates
  • 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

6. Security Considerations


7. IANA Considerations


8. Acknowledgements

The authors would like to thank those that have worked on similar items and/or whom have provided input into this document, especially: Hannes Tschofenig, Henk Birkholz, Heather Flanagan, Kaliya Young, Orie Steele, Leif Johansson, Pamela Dingle, Tobias Looker, Kristina Yasuda, Daniel Fett, Oliver Terbu, and Michael Jones.

9. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

Authors' Addresses

Michael Prorock
Brent Zundel
Gen Digital