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.)
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 10. Registry of protocols for requesting digital credential.
Presentation response
A format that a holder's software, such as a digital wallet, uses, via an exchange protocol, to respond to a query by a verifier.
query
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 the Navigator interface

WebIDLpartial interface Navigator {
  [SecureContext, SameObject] readonly attribute CredentialsContainer identity;
};

4.1 The identity attribute

The identity attribute provides access to the the underlying CredentialsContainer for managing digital credentials.

5. Extensions to CredentialRequestOptions dictionary

WebIDLpartial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

5.1 The digital member

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

6. The DigitalCredentialRequestOptions dictionary

WebIDLdictionary DigitalCredentialRequestOptions {
  sequence<IdentityRequestProvider> providers;
};

6.1 The providers member

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

7. The IdentityRequestProvider dictionary

The IdentityRequestProvider dictionary is used to specify an exchange protocol and a query, which the user agent MAY match against software used by a holder, such as a digital wallet.

WebIDLdictionary IdentityRequestProvider {
  required DOMString protocol;
  required object request;
};

7.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 10. Registry of protocols for requesting digital credential or any other custom one.

7.2 The request member

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

8. 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 {
  readonly attribute DOMString protocol;
  readonly attribute any data;
};

DigitalCredential instances are origin bound.

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

8.2 The protocol member

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

8.3 The data member

Issue: Why the 'any' data type?

The data member is the credential's response data.

8.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. Issue
  7. Return a DigitalCredential.

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

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

8.7 [[type]] internal slot

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

8.8 [[discovey]] internal slot

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

9. Permissions Policy integration

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

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

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

11. IDL Index

WebIDLpartial interface Navigator {
  [SecureContext, SameObject] readonly attribute CredentialsContainer identity;
};

partial dictionary CredentialRequestOptions {
  DigitalCredentialRequestOptions digital;
};

dictionary DigitalCredentialRequestOptions {
  sequence<IdentityRequestProvider> providers;
};

dictionary IdentityRequestProvider {
  required DOMString protocol;
  required object request;
};

[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  readonly attribute DOMString protocol;
  readonly attribute any data;
};

12. 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/
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; 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. 24 July 2024. 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-2.0]
Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen. W3C. 23 August 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. 19 March 2024. W3C Working Draft. URL: https://www.w3.org/TR/permissions/
[w3c-process]
W3C Process Document. Elika J. Etemad (fantasai); Florian Rivoal. W3C. 2 November 2021. URL: https://www.w3.org/Consortium/Process/
[webauthn]
Web Authentication:An API for accessing Public Key Credentials Level 1. Dirk Balfanz; Alexei Czeskis; Jeff Hodges; J.C. Jones; Michael Jones; Akshay Kumar; Huakai Liao; Rolf Lindemann; Emil Lundberg. W3C. 4 March 2019. W3C Recommendation. URL: https://www.w3.org/TR/webauthn-1/