Skip to content

Mention VP & VCI privacy considerations sections #310

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Mention VP & VCI privacy considerations sections #310

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
2 changes: 2 additions & 0 deletions openid4vc-high-assurance-interoperability-profile-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -401,6 +401,8 @@ Implementers need to ensure appropriate key sizes are used. Guidance can be foun

# Privacy Considerations

Note that privacy considerations for OpenID for Verifiable Credential Issuance are defined in Section 15 of [@!OIDF.OID4VCI] and for OpenID for Verifiable Presentations in Section 15 (for redirect based flows) or Section A.6 (for DC API) of [@!OIDF.OID4VP].
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Note that privacy considerations for OpenID for Verifiable Credential Issuance are defined in Section 15 of [@!OIDF.OID4VCI] and for OpenID for Verifiable Presentations in Section 15 (for redirect based flows) or Section A.6 (for DC API) of [@!OIDF.OID4VP].
Privacy considerations for OpenID for Verifiable Credential Issuance are defined in Section 15 of [@!OIDF.OID4VCI] and for OpenID for Verifiable Presentations in Section 15 (for redirect based flows) or Section A.6 (for DC API) of [@!OIDF.OID4VP].
They MUST be followed where applicable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we're changing the language here we should probably change it for security considerations too unless there's a reason for them to differ?

"MUST be followed where applicable" it kind of like a SHOULD, and at least the VCI privacy considerations already have SHOULDs (which are already normative when following HIAP) - I'm not sure what the aim of adding normative text here is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed on today's WG call; consensus to keep the same form as we used for security considerations and as is currently used in this PR, i.e. that we're not trying to change the normative status of the existing privacy considerations.


## 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.
Expand Down