Digital Credentials

Draft Community Group Report

Latest published version:
none
Latest editor's draft:
https://wicg.github.io/digital-credentials/
Editors:
Marcos Caceres (Apple Inc.)
Tim Cappalli (Okta)
Sam Goto (Google Inc.)
Feedback:
GitHub WICG/digital-credentials (pull requests, new issue, open issues)

Abstract

This document specifies an API to enable user agents to mediate access to, and presentation of, digital credentials such as a driver's license, government-issued identification card, and/or other types of digital credential. The API builds on Credential Management Level 1 as a means by which to request a digital credential from a user agent or underlying platform.

Status of This Document

This is a preview

Do not attempt to implement this version of the specification. Do not reference this version as authoritative in any way. Instead, see https://wicg.github.io/digital-credentials/ for the Editor's draft.

This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

This is an unofficial proposal.

GitHub Issues are preferred for discussion of this specification.

1. Introduction

TBW

There are many types of digital credential that can be conveyed using this API. Examples of these types include:

2. Model

Note: Definitions under discussion

The goal of the definitions in this section is to reuse or establish terminology that is common across a variety of digital credential formats and protocols. Discussions surrounding these definitions are active and the definitions are likely to change over the next several months.

Digital credential
A cryptographically signed digital document containing one or more claims made by an issuer about one or more subjects.
Note: Focus on digital credentials about people

This specification is currently focused on digital credentials pertaining to people.

Exchange protocol
A protocol used for exchanging a digital credential between a holder and a verifier. See section 9. Registry of protocols for requesting digital credential.
Presentation request
A presentation request is a request for a digital credential composed of request data and a exchange protocol.
Presentation response
A format that a holder's software, such as a digital wallet, uses, via an exchange protocol, to respond to a request data by a verifier.
request data
A format that verifier software or a user agent uses, via an exchange protocol, to request a digital credential from a holder.

3. Scope

The following items are within the scope of this specification:

The following items are out of scope:

4. Extensions to CredentialRequestOptions dictionary

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

4.1 The digital member

The digital member allows for options to configure the request for a digital credential.

5. The DigitalCredentialRequestOptions dictionary

WebIDLdictionary DigitalCredentialRequestOptions {
  sequence<DigitalCredentialsRequest> requests;
};

5.1 The requests member

The requests specify an exchange protocol and request data, which the user agent MAY match against a holder's software, such as a digital wallet.

6. The DigitalCredentialsRequest dictionary

The DigitalCredentialsRequest dictionary represents a presentation request. It is used to specify an exchange protocol and a request data, which the user agent MAY match against software used by a holder, such as a digital wallet.

WebIDLdictionary DigitalCredentialsRequest {
  required DOMString protocol;
  required object data;
};

6.1 The protocol member

The protocol member denotes the exchange protocol when requesting an identify credential.

The protocol member's value is be one of the well-defined keys defined in 9. Registry of protocols for requesting digital credential or any other custom one.

6.2 The data member

The data member is the request data to be handled by the holder's software, such as a digital wallet.

7. The DigitalCredential interface

The DigitalCredential interface represents a conceptual digital credential.

User mediation is always "required". Requesting a DigitalCredential credential does not support "conditional", "optional", or "silent" user mediation. If get() is called with anything other than "required", a TypeError will be thrown.

WebIDL[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  [Default] object toJSON();
  readonly attribute DOMString protocol;
  readonly attribute object data;
};

DigitalCredential instances are origin bound.

7.1 Integration with Credential Management API

Issue 65: Credential Management integration spec

The CM spec's Extensions points outlines the following things to do to integrate. Adding as a todo list:

This document provides a generic, high-level API that’s meant to be extended with specific types of credentials that serve specific authentication needs. Doing so is, hopefully, straightforward.

- [X] Define a new interface that inherits from [Credential](https://www.w3.org/TR/credential-management-1/#credential):

Define appropriate:

You might also find that new primitives are necessary. For instance, you might want to return many Credential objects rather than just one in some sort of complicated, multi-factor sign-in process. That might be accomplished in a generic fashion by adding a getAll() method to CredentialsContainer which returned a sequence<Credential>, and defining a reasonable mechanism for dealing with requesting credentials of distinct types.

For any such extension, we recommend getting in touch with [public-webappsec@](mailto:public-webappsec@w3.org) for consultation and review.

7.2 The protocol member

The protocol member is the exchange protocol that was used to request the digital credential.

7.3 The data member

The data member is the credential's response data. It contains the subset of JSON-parseable object types.

7.4 [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal method

When invoked, the [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal method MUST:

  1. Let global be this's relevant global object.
  2. Let document be global's associated Document.
  3. If document is not a fully active descendant of a top-level traversable with user attention, throw "NotAllowedError" DOMException.
  4. If window does not have transient activation, throw "NotAllowedError" DOMException.
  5. Consume user activation of window.
  6. Let requests be options's digital's requests member.
  7. If requests is empty, throw a TypeError.
  8. For each request of requests:
    1. Serialize request to a JSON string. Re-throw any exception.
  9. Issue
  10. Return a DigitalCredential.

7.5 [[Store]](credential, sameOriginWithAncestors) internal method

When invoked, the [[Store]](credential, sameOriginWithAncestors) MUST call the default implementation of Credential's [[Store]](credential, sameOriginWithAncestors) internal method with the same arguments.

7.6 [[Create]](origin, options, sameOriginWithAncestors) internal method

When invoked, the [[Create]](origin, options, sameOriginWithAncestors) internal method MUST call the default implementation of Credential's [[Create]](origin, options, sameOriginWithAncestors) internal method with the same arguments.

7.7 [[type]] internal slot

The DigitalCredential interface object has an internal slot named [[type]] whose value is "digital".

7.8 [[discovey]] internal slot

The DigitalCredential interface object has an internal slot named [[discovery]] whose value is "remote".

8. Permissions Policy integration

This specification defines a policy-controlled feature identified by the string "digital-credentials-get". Its default allowlist is 'self'.

9. Registry of protocols for requesting digital credential

The following is the registry of exchange protocols that are supported by this specification.

Note: Official Registry

It is expected that this registry will be become a W3C registry in the future.

9.1 Inclusion criteria

To be included in the registry...

Issue 58: Registry inclusion criteria

We need to come up with a registry governance and inclusion criteria.

For inclusion, at a minimum, there should be implementation support, and we talked about having some privacy checks too.

User agents MUST support the following exchange protocols:

Table of officially registered exchange protocols.
Protocol identifier Description Specification
Coming soon...

10. Security Considerations

This section is non-normative.

Issue: Work in Progress

This section is a work in progress as this document evolves.

The documents listed below outline initial security considerations for Digital Credentials, both broadly and for presentation on the web. Their contents will be integrated into this document gradually.

11. Privacy Considerations

This section is non-normative.

Issue: Work in Progress

This section is a work in progress as this document evolves.

The documents listed below outline various privacy considerations for Digital Credentials, both broadly and for presentation on the web. Their contents will be integrated into this document gradually.

12. Accessibility Considerations

This section is non-normative.

Issue: Work in Progress

This section is a work in progress as this document evolves.

13. IDL Index

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

dictionary DigitalCredentialRequestOptions {
  sequence<DigitalCredentialsRequest> requests;
};

dictionary DigitalCredentialsRequest {
  required DOMString protocol;
  required object data;
};

[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  [Default] object toJSON();
  readonly attribute DOMString protocol;
  readonly attribute object data;
};

14. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY and MUST 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.

A. References

A.1 Normative references

[credential-management-1]
Credential Management Level 1. Nina Satragno; Marcos Caceres. W3C. 13 August 2024. W3C Working Draft. URL: https://www.w3.org/TR/credential-management-1/
[fetch]
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[permissions-policy]
Permissions Policy. Ian Clelland. W3C. 13 January 2025. W3C Working Draft. URL: https://www.w3.org/TR/permissions-policy-1/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[vc-data-model]
Verifiable Credentials Data Model v1.1. Manu Sporny; Grant Noble; Dave Longley; Daniel Burnett; Brent Zundel; Kyle Den Hartog. W3C. 3 March 2022. W3C Recommendation. URL: https://www.w3.org/TR/vc-data-model/
[vc-data-model-2.0]
Verifiable Credentials Data Model v2.0. Ivan Herman; Michael Jones; Manu Sporny; Ted Thibodeau Jr; Gabe Cohen. W3C. 19 December 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
[WEBIDL]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

A.2 Informative references

[permissions]
Permissions. Marcos Caceres; Mike Taylor. W3C. 20 December 2024. W3C Working Draft. URL: https://www.w3.org/TR/permissions/
[w3c-process]
W3C Process Document. Elika J. Etemad (fantasai); Florian Rivoal. W3C. 3 November 2023. URL: https://www.w3.org/policies/process/