Digital Credential Profiles Best Current Practices

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 24 June 2024.¶

Copyright Notice

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

Verifiers have digital credential requirements that reduce their liability, improve their transaction throughput, comply with local, regional, or international laws, and support their environmental, social and governance objectives and values.¶

Requirements are often expressed as "Policy Documents", and furnished to holders, to enable them to easily comply. For example, sometimes to receive a new credential, a holder may need to present one or more existing credentials, and different regional agencies might have unique requirements regarding the quality, age, and issuing authority of these credentials.¶

Not all the attributes of a credential may be necessary to disclose, and the details of the serialization are often less relevant to the verifier than the authenticity and integrity of the credential attributes.¶

Verifiers need to update their policies as new credential formats become available, but still need to ensure that mandatory attributes are disclosed, even while changing the securing mechanisms and serialization details.¶

Depending on how a verifier wrote their policy, the process of updating it to take advantage of new capabilities, safer cryptography, smaller message sizes, or advances in data minimization, can be difficult.¶

This document provides guidance to policy writers, enabling them to construct policies that can be translated into human and machine verifiable profiles, enabling digital credential formats to evolve with the speed and precision at which policies can be written.¶

2. Terminology

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.¶

Ontology:

a set of concepts and categories in a subject area or domain that shows their properties and the relations between them. (oxford dictionary citation fixme)¶

3. Ontologies

Verifiers can share their view of a subject area or domain by acknowledging or leveraging ontologies. Ontologies can be leveraged to model information requirements, with or without requiring the data format to explicitly encode the ontology or leverage the ontology directly in the construction of digital credentials.¶

For example, the ontology defined in [I-D.draft-petithuguenin-rfc-ontology] can be used to describe the information required in a digital credential for RFCs, without requiring the digital credential to contain the literal strings used to serialize the ontology, for example the string: "ftp://shalmaneser.org/rfc#area", need not be present, so long as the verifier describes that the string "area" is equivalent in their profile text.¶

Policy writers SHOULD distinguish between the information they require, and the ontologies that can express the concepts needed to understand the information.¶

4. Information vs Data

Information is abstract, we can express the same information in many different ways, including in many different serializations.¶

The following statement for example, expresses information:¶

Alice believes Bob is 42 years old.

That can also be expressed in different data structures, while preserving the information:¶

in JSON:¶

{
  "alice": {
    "knows": {
      "bob": {
        "age": {
          "42": "years"
        }
      }
    }
  }
}

Verifiers can write policies that mandate a single method to encode information in a serialization and allow only one serialization. This can reduce both the cost to implement and the attack surface associated with the digital credentials that are acceptable to the verifier.¶

However, if a new serialization is invented, that is simpler to support, and more directly aligns with the values of the verifier and their mission objectives, having such a policy could prevent the verifier from adopting the new and improved serialization, even if it secures the same information and provides additional benefits, beyond integrity and authenticity, such as compactness, reduced computation and storage costs, or safer formal modeling capabilities.¶

Policy writers SHOULD distinguish between the information they require, and the acceptable serializations that can express this information required.¶

5. Schema vs Definition

Once a verifier has documented their information requirements, and selected data formats capable of expressing the required information while satisfying their policies and values, the details of the acceptable data format SHOULD be considered.¶

There are a number of subtle details regarding octet encodings that can lead to security or performance issues in digital credential formats.¶

For example, understanding the allowed data types for expressing information, be it an integer, a floating point number, a string, or a boolean value.¶

Policy writers SHOULD describe the allowed data types for the expression of information, and SHOULD NOT support polymorphic types.¶

Schema or data definition languages such as [RFC8610] SHOULD be used when describing acceptable expressions of information models, so that validation of data instances can be automated.¶

6. Designing Data Structures

Although schema or data definition languages can help address some common security issues such as validation as described in [RFC4949], there are still problematic expressions of information which should generally be avoided even when fully specifying data.¶

Most commonly deeply nested data structures, or lists of deeply nested data structures containing lists.¶

Most digital credentials are about asserting attributes of a subject, in a way that is secured by the issuer, and provable by the holder.¶

This can naturally be expressed using a simple map data type.¶

subject-attributes = {
  ; identifier
  ? &(id: 1) => int,
  ; age
  ? &(age: 2) => int,
}

Strings and arbitrary length data structures SHOULD be avoided, whenever possible.¶

As the issuer secures the data, the interpretation of the data is always in the context of:¶

1. the definitions published by the issuer.¶

2. the data the issuer chose to secure that expresses the information.¶

Policy writers SHOULD leverage tabular data structures (tables, csv) whenever possible.¶

Policy writers SHOULD externalize definitions of data structures wherever possible, and use those external definitions to generate relevant sections of the policy document.¶

Policy writers SHOULD ensure that output documents are computer readable, and that when tabular data is embedded in a policy document, that it is clearly separated from other sections of tabular data.¶

Documents SHOULD be sectioned by logical concepts, and document sections dealing with the description of data structures SHOULD be clearly identifed and not mixed with other data structure descriptions without clear separation.¶

Policy writers SHOULD clearly version policy documents, and SHOULD clearly identify the date of publication, start date of applicabiilty of the policy, and if known, the end date of applicability.¶

Policy writers SHOULD clearly define the scope of the policy, and the audience to which the policy applies to. These scope and audience definitions SHOULD take place in their own sections.¶

Policy writers SHOULD restrict what data is expressed in a digital credential and how the data is expressed not just the information that is required to be present.¶

Policy writers SHOULD avoid making recommendations where the same information may be conveyed in many different, but equivalent data structures. When leveraging CBOR, [I-D.draft-ietf-cbor-cde] SHOULD be used.¶

Policy writers should avoid creating "frameworks" where interoperability is not immediately available [RFC9518].¶

7. Security Considerations

TODO Security¶

8. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses