Add support for the Digital Credentials API #476

leecam · 2025-03-31T22:50:31Z

Adds a new annex to defining support for the DC API

closes #410

Adds a new annex to defining support for the DC API

leecam · 2025-03-31T22:51:29Z

Still work in progress, but can get some initial comments

leecam · 2025-03-31T22:51:53Z

openid-4-verifiable-credential-issuance-1_0.md

+
+* `status`: REQUIRED. A string containing one of the status codes defined in this section.
+
+The following status codes are supported:


TODO: Need to decide what error codes to support here.

probably offer_declined?

paulbastian

Looks good so far, some minor suggestions

paulbastian · 2025-04-07T21:53:45Z

openid-4-verifiable-credential-issuance-1_0.md

+          credential_issuer: "...",
+          credential_configuration_ids: [...],
+          grants: {...}
+          credential_issuer_metadata: {...},
+          authorization_server_metadata: {...}


Grouping it like this, may enable to reuse the existing object used from vanilla vci flows

Suggested change

credential_issuer: "...",

credential_configuration_ids: [...],

grants: {...}

credential_issuer_metadata: {...},

authorization_server_metadata: {...}

credential-offer: {

credential_issuer: "...",

credential_configuration_ids: [...],

grants: {...}

}

credential_issuer_metadata: {...},

authorization_server_metadata: {...}

paulbastian · 2025-04-07T22:03:27Z

openid-4-verifiable-credential-issuance-1_0.md

+
+## Credential Offer {#dc_api_credential_offer}
+
+The Issuer sends the Credential Offer object to the Digital Credentials API. All of the Credential Offer parameters MAY be used. The Credential Offer object has been extended to include the following parameters:


Suggested change

The Issuer sends the Credential Offer object to the Digital Credentials API. All of the Credential Offer parameters MAY be used. The Credential Offer object has been extended to include the following parameters:

The Issuer sends the Credential Offer object to the Digital Credentials API. All of the Credential Offer parameters MAY be used. As some implementations of the DC API may not allow to network calls, the Credential Offer object is extended to include the following parameters:

I think it's more "to allow all the installed wallets to figure out if they can handle the request without fetching external data that may result in data being leaked without user consent"? Not sure.

Agree with @jogu as its highlighting why some DC API implementations have this limitation.

paulbastian · 2025-04-07T22:16:32Z

openid-4-verifiable-credential-issuance-1_0.md

+
+
+* `credential_issuer_metadata`: REQUIRED. The Issuer's Credential Issuer Metadata object as defined in (#credential-issuer-parameters).
+* `authorization_server_metadata`: OPTIONAL. The Authorization Server metadata object as defined by Section 2 of [@!RFC8414]. When provided the `authorization_server` parameter must not be present.


Suggested change

* `authorization_server_metadata`: OPTIONAL. The Authorization Server metadata object as defined by Section 2 of [@!RFC8414]. When provided the `authorization_server` parameter must not be present.

* `authorization_server_metadata`: REQUIRED. The Authorization Server metadata object as defined in (#as-metadata).

paulbastian · 2025-04-07T22:19:34Z

openid-4-verifiable-credential-issuance-1_0.md

+
+* `status`: REQUIRED. A string containing one of the status codes defined in this section.
+
+The following status codes are supported:


probably offer_declined?

paulbastian · 2025-04-07T22:20:39Z

openid-4-verifiable-credential-issuance-1_0.md

+
+* `openid4vci-v1`
+
+## Credential Offer {#dc_api_credential_offer}


I see potential for other requests, i.e. calling DC-API to continue a deferred issuance with transaction_id

Do you mean like using the DC API to notify the wallet that a deferred issuance is now ready for issuance?

c2bo · 2025-04-07T22:46:46Z

openid-4-verifiable-credential-issuance-1_0.md

+The Issuer sends the Credential Offer object to the Digital Credentials API. All of the Credential Offer parameters MAY be used. The Credential Offer object has been extended to include the following parameters:
+
+
+* `credential_issuer_metadata`: REQUIRED. The Issuer's Credential Issuer Metadata object as defined in (#credential-issuer-parameters).


feels somewhat redundant?

Suggested change

* `credential_issuer_metadata`: REQUIRED. The Issuer's Credential Issuer Metadata object as defined in (#credential-issuer-parameters).

* `credential_issuer_metadata`: REQUIRED. The Credential Issuer Metadata object as defined in (#credential-issuer-parameters).

Sakurann · 2025-04-25T21:08:48Z

openid-4-verifiable-credential-issuance-1_0.md

+The name "Digital Credentials API" (DC API) encompasses the W3C Digital Credentials API [@!W3C.Digital_Credentials_API]
+as well as its native App Platform equivalents in operating systems (such as [Credential Manager on Android](https://developer.android.com/jetpack/androidx/releases/credentials)).
+The DC API allows web sites and native apps acting as Issuers to initiate the issuance of verifiable credentials.
+The API itself is agnostic to the Credential issuance protocol and can be used with different protocols.
+The Web Platform, working in conjunction with other layers, such as the app platform/operating system, and based on the permission of the End-User, will send the credential offer along with the Origin of the Issuer to the End-User's chosen Wallet.


Suggested change

The name "Digital Credentials API" (DC API) encompasses the W3C Digital Credentials API [@!W3C.Digital_Credentials_API]

as well as its native App Platform equivalents in operating systems (such as [Credential Manager on Android](https://developer.android.com/jetpack/androidx/releases/credentials)).

The DC API allows web sites and native apps acting as Issuers to initiate the issuance of verifiable credentials.

The API itself is agnostic to the Credential issuance protocol and can be used with different protocols.

The Web Platform, working in conjunction with other layers, such as the app platform/operating system, and based on the permission of the End-User, will send the credential offer along with the Origin of the Issuer to the End-User's chosen Wallet.

The term "Digital Credentials API" (DC API) encompasses the W3C Digital Credentials API [@!W3C.Digital_Credentials_API]

as well as its native App Platform equivalents in operating systems (such as [Credential Manager on Android](https://developer.android.com/jetpack/androidx/releases/credentials)).

The API itself is agnostic to the Credential issuance protocol and can be used with different protocols.

When the DC API is used with this specification, it allows web sites and native apps acting as Issuers to initiate the issuance of verifiable credentials.

The Web Platform, working in conjunction with other layers, such as the app platform/operating system, and based on the permission of the End-User, will send the Credential Offer along with the Origin of the Issuer to the End-User's chosen Wallet.

tplooker · 2025-04-27T03:28:46Z

openid-4-verifiable-credential-issuance-1_0.md

+
+To use OpenID4VCI with the Digital Credentials API (DC API), the exchange protocol value has the following format: `openid4vci-v<version>`.
+
+The value `1` MUST be used for the `<version>` field to indicate the request and response are compatible with this version of the specification.


Do we need to be explicit here that the version essentially constitutes a MAJOR version as per semver and therefore implementations should adopt the robustness principle when it comes to things like ignoring unknown elements in maps/objects to support forward compatibility with minor changes?

tlodderstedt · 2025-05-27T16:49:29Z

openid-4-verifiable-credential-issuance-1_0.md

+
+The following status codes are supported:
+
+`offer_accepted`:


Clarifying question: is the idea the issuer sends the offer and gets a confirmation from the wallet, but the actual issuance happens in a separate, parallel process within the wallet?

That would be my understanding right now, the DC API flow basically succeeds with reaching a wallet and the "real" issuance flow starts from there from the Wallet.

Add support for the Digital Credentials API

0ce0019

Adds a new annex to defining support for the DC API

leecam commented Mar 31, 2025

View reviewed changes

leecam requested review from c2bo, paulbastian, tlodderstedt and Sakurann March 31, 2025 22:52

paulbastian requested changes Apr 7, 2025

View reviewed changes

c2bo reviewed Apr 7, 2025

View reviewed changes

Sakurann reviewed Apr 25, 2025

View reviewed changes

tplooker reviewed Apr 27, 2025

View reviewed changes

tlodderstedt reviewed May 27, 2025

View reviewed changes


		* `status`: REQUIRED. A string containing one of the status codes defined in this section.

		The following status codes are supported:


		## Credential Offer {#dc_api_credential_offer}

		The Issuer sends the Credential Offer object to the Digital Credentials API. All of the Credential Offer parameters MAY be used. The Credential Offer object has been extended to include the following parameters:



		* `credential_issuer_metadata`: REQUIRED. The Issuer's Credential Issuer Metadata object as defined in (#credential-issuer-parameters).
		* `authorization_server_metadata`: OPTIONAL. The Authorization Server metadata object as defined by Section 2 of [@!RFC8414]. When provided the `authorization_server` parameter must not be present.

	* `authorization_server_metadata`: OPTIONAL. The Authorization Server metadata object as defined by Section 2 of [@!RFC8414]. When provided the `authorization_server` parameter must not be present.
	* `authorization_server_metadata`: REQUIRED. The Authorization Server metadata object as defined in (#as-metadata).


		* `openid4vci-v1`

		## Credential Offer {#dc_api_credential_offer}


		To use OpenID4VCI with the Digital Credentials API (DC API), the exchange protocol value has the following format: `openid4vci-v<version>`.

		The value `1` MUST be used for the `<version>` field to indicate the request and response are compatible with this version of the specification.

Add support for the Digital Credentials API #476

Are you sure you want to change the base?

Add support for the Digital Credentials API #476

Uh oh!

Conversation

leecam commented Mar 31, 2025 • edited by jogu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

leecam commented Mar 31, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulbastian left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tplooker Apr 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

c2bo May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

leecam commented Mar 31, 2025 •

edited by jogu

Loading

tplooker Apr 27, 2025 •

edited

Loading

c2bo May 27, 2025 •

edited

Loading