-
assigned issue to
OpenID4VCs: Security & Trust Model Document
Issue #1562
resolved
We need a comprehensive analysis and description of the security of the OpenID4VCs protocol family, which also includes the underlying trust model. It is important to conduct the analysis end 2 end for the whole family since there are interdependencies.
Here are just some initial thoughts:
- Authentic claims - signed data by a trusted issuer
- trusted issuer - signed data / identification of issuer / management of trusted issuers
- Prevention of copying/replay of credentials / impersonation - holder binding (cryptographic, biometric, claims-based)
- Security of cryptographic holder binding - attestation of different kind
- Trustworthiness of processing by wallet - 3rd party verification / confirmation
- Design philosophy: issuer does the heavy lift, verifier can be sure all pre-requisites are fulfilled by wallet if there exists a credential issued by a trusted issuer (since it conforms to its policy)
- Confidentially of user claims - protected cloud systems / encryption on rest, encrypted transmission
- Issuance - Do we need nonce and audience in issuance?
- Impersonation by attacker - authentication to wallet
Comments (8)
-
reporter -
Specify conceptual models first.
Re: design philosophy. Keep it simple, pin down options to mimimum for viable open interworking.
-
reporter - changed status to open
-
there is also Issue
#1556for VP spec:
- How does a verifier establish trust in a wallet, esp. its ability to handle key material securely?
- presentation_submission is unsigned metadata, handle with care
-
also
#1516 -
also
#1425 -
As discussed on today’s call, response_mode=post probably opens up some reflection/open proxy style attacks, and Brian commented that the cross-device flow in general likely has more.
-
- changed status to resolved
Migrated to GitHub
- Log in to comment