diff --git a/1.0/openid-4-verifiable-presentations-1_0.md b/1.0/openid-4-verifiable-presentations-1_0.md index 0b2e4660..ed91213f 100644 --- a/1.0/openid-4-verifiable-presentations-1_0.md +++ b/1.0/openid-4-verifiable-presentations-1_0.md @@ -121,7 +121,7 @@ Issuer-Holder-Verifier Model: : A model for exchanging claims, where claims are issued in the form of Credentials independent of the process of presenting them as Presentations to the Verifiers. An issued Credential may be used multiple times. Origin: -: An identifier for the calling website or native application, asserted by the web or app platform. A web origin is the combination of a scheme/protocol, host, and port, with port being omitted when it matches the default port of the scheme. An app platform may use a linked web origin, or use a platform-specific URI for the app origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The web origin is `https://verify.example.com` with `https` being the scheme, `verify.example.com` being the host, and the port is not explicitly included as `443` is the default port for the protocol `https`. The native applications origin on some platforms will also be `https://verify.example.com` and on other platforms, may be `platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0`. +: An identifier for the calling website or native application, asserted by the underlying web or application platform. For Web-based callers, the Origin is an opaque `origin` or `tuple origin` as defined in the "Origins" section of [@!whatwg.html]. For native application callers, the Origin follows a platform-specific convention. Some platforms use a linked web origin, while others use a platform-specific application origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The corresponding web Origin is https://verify.example.com, where https is the scheme, verify.example.com is the host, and the port is not explicitly included because 443 is the default port for https. On some platforms, a native application uses the same Origin, while on others it uses a platform-specific value such as platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0. The Origin provided by the underlying platform is outside the scope of this specification and MUST be treated as an opaque string. Presentation: : Data that is presented to a specific Verifier, derived from a Credential. In this specification, Presentations are usually Verifiable Presentations including Holder Binding (as defined below), but may also be Presentations without Holder Binding (discussed in (#nkb-credentials)). @@ -2389,6 +2389,17 @@ Ecosystems intending to use trusted authority mechanisms SHOULD ensure that the + + + HTML - Living Standard + + WHATWG + + + + Commit snapshot: https://html.spec.whatwg.org/commit-snapshots/c560a56704e7a31887ab79299d30e6f68d696cf4/#concept-origin + + # OpenID4VP over the Digital Credentials API {#dc_api} This section defines how to use OpenID4VP with the Digital Credentials API. @@ -2410,7 +2421,7 @@ Secondly, the session with the End-User will always continue in the initial cont Thirdly, cross-device requests benefit from the use of secure transports with proximity checks, which are handled by the OS platform, e.g., using FIDO CTAP 2.2 with hybrid transports. -And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the user agent, which is important for phishing resistance. +And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the trusted platform (i.e. user agent), which is important for phishing resistance. ## Protocol @@ -2461,7 +2472,7 @@ The value of the `response_mode` parameter MUST be `dc_api` when the response is In addition to the above-mentioned parameters, a new parameter is introduced for OpenID4VP over the W3C Digital Credentials API: -* `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). A non-empty array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet MUST compare values in this parameter to the Origin to detect replay of the request from a malicious Verifier. If the Origin does not match any of the entries in `expected_origins`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. +* `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). A non-empty array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet MUST compare values in this parameter to the provided Origin, treated as a string, using simple string comparison, without any prior processing or interpretation of either the `expected_origins` values or the provided Origin, to detect replay of the request from a malicious Verifier. Values using unsafe or unsupported URI schemes, including `ftp`, `javascript`, `data`, `ws`, and `wss`, MUST NOT be used. Values using the http scheme MUST NOT be used unless they are explicitly allowed for constrained scenarios such as local development or equivalent non-production environments. If the Origin does not match any of the entries in `expected_origins`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. The transport of the request and Origin to the Wallet is platform-specific and is out of scope of OpenID4VP over the Digital Credentials API. @@ -3593,6 +3604,8 @@ The technology described in this specification was made available from contribut * Clarify nonce entropy requirements * Clarify that state is recommended to match text from Section 14.3.2. Protection of the Response URI * Clarify that `encrypted_response_enc_values_supported` applies only if JWE content encryption algorithm is used + * Clarify provided Origin is a string without prior interpretation and validation is based on simple string comparison + * Add assumption that the platform that provides the Origin is trusted * Clarified intent_to_retain value when not present * Removed invalid_scope error guidance as duplicate of RFC6749 * Clarified that Multi-RP-sig section means Verifier Info instead of attestations diff --git a/1.1/openid-4-verifiable-presentations-1_1.md b/1.1/openid-4-verifiable-presentations-1_1.md index b31762ff..58fa4009 100644 --- a/1.1/openid-4-verifiable-presentations-1_1.md +++ b/1.1/openid-4-verifiable-presentations-1_1.md @@ -117,7 +117,7 @@ Issuer-Holder-Verifier Model: : A model for exchanging claims, where claims are issued in the form of Credentials independent of the process of presenting them as Presentations to the Verifiers. An issued Credential may be used multiple times. Origin: -: An identifier for the calling website or native application, asserted by the web or app platform. A web origin is the combination of a scheme/protocol, host, and port, with port being omitted when it matches the default port of the scheme. An app platform may use a linked web origin, or use a platform-specific URI for the app origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The web origin is `https://verify.example.com` with `https` being the scheme, `verify.example.com` being the host, and the port is not explicitly included as `443` is the default port for the protocol `https`. The native applications origin on some platforms will also be `https://verify.example.com` and on other platforms, may be `platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0`. +: An identifier for the calling website or native application, asserted by the underlying web or application platform. For Web-based callers, the Origin is an opaque `origin` or `tuple origin` as defined in the "Origins" section of [@!whatwg.html]. For native application callers, the Origin follows a platform-specific convention. Some platforms use a linked web origin, while others use a platform-specific application origin. For example, the Verifier for the organization MyExampleOrg is served from https://verify.example.com. The corresponding web Origin is https://verify.example.com, where https is the scheme, verify.example.com is the host, and the port is not explicitly included because 443 is the default port for https. On some platforms, a native application uses the same Origin, while on others it uses a platform-specific value such as platform:pkg-key-hash:Z4OFzVVSZrzTRa3eg79hUuHy12MVW0vzPDf4q4zaPs0. The Origin provided by the underlying platform is outside the scope of this specification and MUST be treated as an opaque string. Presentation: : Data that is presented to a specific Verifier, derived from a Credential. In this specification, Presentations are usually Verifiable Presentations including Holder Binding (as defined below), but may also be Presentations without Holder Binding (discussed in (#nkb-credentials)). @@ -2453,6 +2453,17 @@ Ecosystems intending to use trusted authority mechanisms SHOULD ensure that the + + + HTML - Living Standard + + WHATWG + + + + Commit snapshot: https://html.spec.whatwg.org/commit-snapshots/c560a56704e7a31887ab79299d30e6f68d696cf4/#concept-origin + + # OpenID4VP over the Digital Credentials API {#dc_api} This section defines how to use OpenID4VP with the Digital Credentials API. @@ -2474,7 +2485,7 @@ Secondly, the session with the End-User will always continue in the initial cont Thirdly, cross-device requests benefit from the use of secure transports with proximity checks, which are handled by the OS platform, e.g., using FIDO CTAP 2.2 with hybrid transports. -And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the user agent, which is important for phishing resistance. +And lastly, as part of the request, the Wallet is provided with information about the Verifier's Origin as authenticated by the trusted platform (i.e., user agent), which is important for phishing resistance. ## Protocol @@ -2525,7 +2536,7 @@ The value of the `response_mode` parameter MUST be `dc_api` when the response is In addition to the above-mentioned parameters, a new parameter is introduced for OpenID4VP over the W3C Digital Credentials API: -* `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). A non-empty array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet MUST compare values in this parameter to the Origin to detect replay of the request from a malicious Verifier. If the Origin does not match any of the entries in `expected_origins`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. +* `expected_origins`: REQUIRED when signed requests defined in (#signed_request) are used with the Digital Credentials API (DC API). A non-empty array of strings, each string representing an Origin of the Verifier that is making the request. The Wallet MUST compare values in this parameter to the provided Origin, treated as a string, using simple string comparison, without any prior processing or interpretation of either the `expected_origins` values or the provided Origin, to detect replay of the request from a malicious Verifier. Values using unsafe or unsupported URI schemes, including `ftp`, `javascript`, `data`, `ws`, and `wss`, MUST NOT be used. Values using the http scheme MUST NOT be used unless they are explicitly allowed for constrained scenarios such as local development or equivalent non-production environments. If the Origin does not match any of the entries in `expected_origins`, the Wallet MUST return an error. This error SHOULD be an `invalid_request` error. This parameter is not for use in unsigned requests and therefore a Wallet MUST ignore this parameter if it is present in an unsigned request. The transport of the request and Origin to the Wallet is platform-specific and is out of scope of OpenID4VP over the Digital Credentials API. @@ -3660,6 +3671,8 @@ The technology described in this specification was made available from contribut * Add security consideration not to use VP Token as Access Token * Clarify that state is recommended to match text from Section 14.3.2. Protection of the Response URI * Clarify that `encrypted_response_enc_values_supported` applies only if JWE content encryption algorithm is used; e.g., it does not apply to JOSE HPKE + * Clarify provided Origin is a string without prior interpretation and validation is based on simple string comparison + * Add assumption that the platform that provides the Origin is trusted * Clarify that `aud` corresponds to `issuer` Wallet Metadata paremeter if Dynamic Discovery is used * Clarified `intent_to_retain` value when not present * Removed invalid_scope error guidance as duplicate of RFC6749