Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

editorial: Wallet is a defined term #82

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

editorial: Wallet is a defined term #82

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4c168f5
editorial: Wallet is a defined term
peppelinux Dec 13, 2023
ab16885
capitalize "wallet"
Sakurann Mar 23, 2024
900442a
Apply suggestions from code review
peppelinux May 24, 2024
1f91c8a
Merge branch 'main' into wa
peppelinux May 24, 2024
666a488
Merge branch 'wa' of https://github.com/peppelinux/oid4vc-haip-sd-jwt…
peppelinux May 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ The audience of the document is implementers that require a high level of securi

# Terminology

This specification uses the terms "Holder", "Issuer", "Verifier", and "Verifiable Credential" as defined in [@!I-D.ietf-oauth-sd-jwt-vc].
This specification uses the terms "Holder", "Issuer", "Verifier", "Wallet", and "Verifiable Credential" as defined in @!OIDF.OID4VCI] and [@!OIDF.OID4VP].

# Scope

Expand All @@ -69,8 +69,8 @@ The following aspects are in scope of this interoperability profile:

Assumptions made are the following:

* The issuers and verifiers cannot pre-discover wallet’s capability
* The issuer is talking to the wallet supporting the features defined in this profile (via wallet invocation mechanism)
* The issuers and verifiers cannot pre-discover Wallet’s capability
* The issuer is talking to the Wallet supporting the features defined in this profile (via Wallet invocation mechanism)
* There are mechanisms in place for the verifiers and issuers to discover each other’s capability

## Out of Scope
Expand Down Expand Up @@ -111,8 +111,8 @@ Both Wallet initiated and Issuer initiated issuance is supported.
## Credential Offer

* The Grant Types `authorization_code` and `urn:ietf:params:oauth:grant-type:pre-authorized_code` MUST be supported as defined in Section 4.1.1 in [@!OIDF.OID4VCI]
* For Grant Type `authorization_code`, the Issuer MUST include a scope value in order to allow the Wallet to identify the desired credential type. The wallet MUST use that value in the `scope` Authorization parameter. For Grant Type `urn:ietf:params:oauth:grant-type:pre-authorized_code`, the pre-authorized code is used by the issuer to identify the credential type(s).
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* For Grant Type `authorization_code`, the Issuer MUST include a scope value in order to allow the Wallet to identify the desired credential type. The Wallet MUST use that value in the `scope` Authorization parameter. For Grant Type `urn:ietf:params:oauth:grant-type:pre-authorized_code`, the pre-authorized code is used by the issuer to identify the credential type(s).
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the Wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.

Note: The Authorization Code flow does not require a Credential Offer from the Issuer to the Wallet. However, it is included in the feature set of the Credential Offer because it might be easier to implement with existing libraries and on top of existing implementations than the pre-authorized code Grant Type.

Expand Down Expand Up @@ -142,9 +142,9 @@ Wallets MUST use attestations following the definition given in [@!I-D.ietf-oaut

In addition to this definition, the Wallet Attestation MAY contain the following claims in the `cnf` element:

* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the Wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud Wallet). This specification defines the following values for `key_type`:
* `key_type`: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to manage the private key associated with the public key given in the `cnf` claim. This mechanism is based on the capabilities of the execution environent of the Wallet, this might be a secure element (in case of a Wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud Wallet). This specification defines the following values for `key_type`:
* `software`: It MUST be used when the Wallet uses software-based key management.
* `hardware`: It MUST be used when the wallet uses hardware-based key management.
* `hardware`: It MUST be used when the Wallet uses hardware-based key management.
* `tee`: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management.
* `secure_enclave`: It SHOULD be used when the Wallet uses the Secure Enclave for key management.
* `strong_box`: It SHOULD be used when the Wallet uses the Strongbox for key management.
Expand All @@ -161,7 +161,7 @@ The Wallet Attestation MAY also contain the following claim:

* `aal`: OPTIONAL. JSON String asserting the authentication level of the Wallet and the key as asserted in the `cnf` claim.

To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key.
To obtain the Issuer's Public key for verification, Wallet attestions MUST support web-based key resolution as defined in Section 5 of [@!I-D.ietf-oauth-sd-jwt-vc]. The JOSE header `kid` MUST be used to identify the respective key.

This is an example of a Wallet Instance Attestation:

Expand All @@ -173,7 +173,7 @@ This is an example of a Wallet Instance Attestation:
}
.
{
"iss": "<identifier of the issuer of this wallet attestation>",
"iss": "<identifier of the issuer of this Wallet attestation>",
"sub": "<`client_id` of the OAuth client>",
"iat": 1516247022,
"exp": 1541493724,
Expand Down Expand Up @@ -202,7 +202,7 @@ This is an example of a Wallet Instance Attestation:
# OpenID for Verifiable Presentations

* MUST support protocol extensions for SD-JWT VC credential format profile as defined in this specification (#vc_sd_jwt_profile).
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the Wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* Response type MUST be `vp_token`.
* Response mode MUST be `direct_post`. The Verifier MUST return `redirect_uri` in response to the HTTP POST request from the Wallet, where the Wallet redirects the User to, as defined in Section 6.2 of [@!OIDF.OID4VP]. Implementation considerations for the response mode `direct_post` are given in Section 11.5 of [@!OIDF.OID4VP].
* Authorization Request MUST be sent using the `request_uri` parameter as defined in JWT-Secured Authorization Request (JAR) [@!RFC9101].
Expand All @@ -220,7 +220,7 @@ This is an example of a Wallet Instance Attestation:

To authenticate the user, subject identifier in a Self-Issued ID Token MUST be used as defined in [@!OIDF.SIOPv2].

* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the Wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* `subject_syntax_types_supported` value MUST be `urn:ietf:params:oauth:jwk-thumbprint`

# SD-JWT VCs {#sd-jwt-vc}
Expand All @@ -242,7 +242,7 @@ In addition, this profile defines the following additional requirements.
|status|SHOULD (at the discretion of the issuer)| [@!I-D.ietf-oauth-status-list]|

* The Issuer MUST NOT make any of the JWT Claims in the table above to be selectively disclosable, so that they are always present in the SD-JWT-VC presented by the Holder.
* It is at the discretion of the Issuer whether to use `exp` claim and/or a `status` claim to express the validity period of an SD-JWT-VC. The wallet and the verifier MUST support both mechanisms.
* It is at the discretion of the Issuer whether to use `exp` claim and/or a `status` claim to express the validity period of an SD-JWT-VC. The Wallet and the verifier MUST support both mechanisms.
* The `iss` claim MUST be an HTTPS URL. The `iss` value is used to obtain Issuer’s signing key as defined in (#issuer-key-resolution).
* The `vct` JWT claim as defined in [@!I-D.ietf-oauth-sd-jwt-vc].
* The `cnf` claim [@!RFC7800] MUST conform to the definition given in [@!I-D.ietf-oauth-sd-jwt-vc]. Implementations conforming to this profile MUST include the JSON Web Key [@!RFC7517] in the `jwk` sub claim.
Expand Down