Use Cases for SPICE
draft-prorock-spice-use-cases-01

None                                                          M. Prorock
Internet-Draft                                                  mesur.io
Intended status: Informational                                 B. Zundel
Expires: 4 September 2024                                    Gen Digital
                                                            3 March 2024

                          Use Cases for SPICE
                    draft-prorock-spice-use-cases-01

Abstract

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

Copyright Notice

   Copyright (c) 2024 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.

Prorock & Zundel        Expires 4 September 2024                [Page 1]
Internet-Draft                   sd-cwt                       March 2024

Table of Contents

   1.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  SPICE Common Patterns . . . . . . . . . . . . . . . . . . . .   2
   4.  SPICE Use Cases . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Use Case Discussion . . . . . . . . . . . . . . . . . . . . .   3
     5.1.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.2.  Physical Supply Chain Credentials . . . . . . . . . . . .   3
     5.3.  Credentials related to Authenticity and Provenance  . . .   4
     5.4.  Others  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

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:

   *  A need for 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

Prorock & Zundel        Expires 4 September 2024                [Page 2]
Internet-Draft                   sd-cwt                       March 2024

   *  Required strong and long lived identities that are correlated with
      public key material for verifiacation and permit binding to DNS,
      existing x509 certificates, as well as providing ready access to
      public keys for verification utilizing HTTP

4.  SPICE Use Cases

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

   *  Use of microcredentials, particularly in education
   *  Digitization of physical supply chain credentials in multiple
      jurisdictions
      -  CBOR credentials
      -  High volume with system to system exchange of credentions
      -  both regulatory data as well as business driven information
   *  IoT, Control Systems, and Critical Infrastructure related
      Credentials
   *  Credentials related to authenticity and provenance, especially of
      digital media
   *  Offline exchange (in person) of credentials that may have been
      internet issued
   *  Embedding of credentials in other data formats
   *  Digital Wallet Initiatives

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.

Prorock & Zundel        Expires 4 September 2024                [Page 3]
Internet-Draft                   sd-cwt                       March 2024

   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

5.3.  Credentials related to Authenticity and Provenance

   Due to a proliferation of AI generated or modified content, there has
   been an increased need to provide the ability to establish the
   provenance of digital material.  Questions of authenticity and the
   means of creation (human created, machine assited, machine created)
   also abound, and in cases where AI generated content, providing the
   model information related to the generation of that content is
   becoming increasingly important.

   Common use cases include:

   *  Understanding if a received piece of media is human created, and
      that the content is authorized for certain uses.
   *  Providing the ability to trace training materials for LLMs and
      similar models to output
   *  Understanding if media was created by an authoritative or
      trustworthy source

5.4.  Others

   TBD

6.  Security Considerations

   TBD

Prorock & Zundel        Expires 4 September 2024                [Page 4]
Internet-Draft                   sd-cwt                       March 2024

7.  IANA Considerations

   NONE

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Michael Prorock
   mesur.io
   Email: mprorock@mesur.io

   Brent Zundel
   Gen Digital
   Email: Brent.Zundel@gendigital.com

Prorock & Zundel        Expires 4 September 2024                [Page 5]