Merge branch 'main' into pb/crossdevice

Author: Sakurann

openid4vc-high-assurance-interoperability-profile-1_0.md

@@ -367,6 +367,20 @@ This specification relies on certain prerequisites, such as browser or operating
 
 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.
 
+## Ecosystem Implementation Considerations
+
+This document intentionally leaves certain extensions for ecosystems to define, in order to enable broad compatibility across differing or even conflicting requirements. These include:
+
+- Whether to adopt the Presentation profile, Issuance profile, or both
+- Which Credential format to support across issuance and presentation
+- Whether to use Signed Issuer Metadata or not
+- How to send Credential Offer
+- Which Key attestation format to use
+- Which Wallet attestation format to use
+- X509 certificate profiles
+- Whether to use DC API, Redirects with custom URL schemes  and/or Redirects with claimed `https` scheme URIs for presentation
+- Support or restriction of additional cryptographic suites and hash algorithms
+
 # Security Considerations {#security_considerations}
 
 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].
@@ -387,7 +401,7 @@ Implementers need to ensure appropriate key sizes are used. Guidance can be foun
 
 # Privacy Considerations
 
-## Interoperable Key Attestations
+## Interoperable Key Attestations {#interop-key-attestations}
 
 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.
 
@@ -662,6 +676,7 @@ The technology described in this specification was made available from contribut
    -05
 
    * mandate support for same device flow for redirect-based OpenID4VP
+   * Add ecosysetm guidance section
    * change wallet attesation format from mandatory to recommended
    * 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
    * removed intent_to_retain mandatory