You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: openid4vc-high-assurance-interoperability-profile-1_0.md
+16-1Lines changed: 16 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -362,6 +362,20 @@ This specification relies on certain prerequisites, such as browser or operating
362
362
363
363
Wallet implementations using the key attestation format specified in Annex D of [@!OIDF.OID4VCI] might need to utilize a transformation (backend) service to create such attestations based on data as provided in other formats by the respective platform or secure key management module. The dependency on such a service might impact the availability of the wallet app as well as the performance of the issuance process. This could be mitigated by creating keys and obtaining the respective key attestations in advance.
364
364
365
+
## Ecosystem Implementation Considerations
366
+
367
+
This document intentionally leaves certain extensions for ecosystems to define, in order to enable broad compatibility across differing or even conflicting requirements. These include:
368
+
369
+
- Whether to adopt the Presentation profile, Issuance profile, or both
370
+
- Which Credential format to support across issuance and presentation
371
+
- Whether to use Signed Issuer Metadata or not
372
+
- How to send Credential Offer
373
+
- Which Key attestation format to use
374
+
- Which Wallet attestation format to use
375
+
- X509 certificate profiles
376
+
- Whether to use DC API, Redirects with custom URL schemes and/or Redirects with claimed `https` scheme URIs for presentation
377
+
- Support or restriction of additional cryptographic suites and hash algorithms
Note that security considerations for OpenID for Verifiable Credential Issuance are defined in Section 13 of [@!OIDF.OID4VCI] and for OpenID for Verifiable Presentations in Section 14 (for redirect based flows) or Section A.5 (for DC API) of [@!OIDF.OID4VP].
@@ -382,7 +396,7 @@ Implementers need to ensure appropriate key sizes are used. Guidance can be foun
Wallet implementations using the key attestation format specified in Annex D of [@!OIDF.OID4VCI] might need to utilize a transformation (backend) service to create such attestations based on data as provided in other formats by the respective platform or secure key management module. Such a backend service MUST be designed considering the privacy of its users. For example, the service could be stateless and just perform the transformation of the attestation data without binding the process in any way to a unique user identifier.
388
402
@@ -656,6 +670,7 @@ The technology described in this specification was made available from contribut
656
670
657
671
-05
658
672
673
+
* Add ecosysetm guidance section
659
674
* change wallet attesation format from mandatory to recommended
660
675
* update crypto suites to require at least ECDSA w/ P-256 and SHA-256 for verifying signed artificats; and made ecosystem-specific exceptions for crypto suites and hash algorithms if certain criteria is not met
0 commit comments