Skip to content
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.

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

Plausibly deniable proof of association #78

Open
sander opened this issue Dec 14, 2024 · 0 comments
Open

Plausibly deniable proof of association #78

sander opened this issue Dec 14, 2024 · 0 comments

Comments

@sander
Copy link
Owner

sander commented Dec 14, 2024

To meet the ARF Topic 18 requirements, we need a proof of association (PoA) method that is:

  • compatible with HDKeys, in particular distributed WSCA
  • plausibly deniable

This will require three protocol steps:

  1. prover shares commitment involving the right keys
  2. verifier shares challenge
  3. prover shares response

After these steps, the verifier can verify whether the prover knows, for example in elliptic curve cryptography, the discrete logarithm of one public key respective to another public key as base point.

The W3C Digital Credentials (DC) API proposal only supports two requests: a credential request and a credential response. So in particular there is no way to directly include protocol step 1, since the prover cannot yet know which are the right keys to use.

One solution is to add a second PoA-HTTP protocol on top:

  1. RP website shares DC credential request, including an RP PoA-HTTP endpoint
  2. User authenticates to WSCA
  3. WSCA shares commitment at PoA-HTTP endpoint
  4. PoA-HTTP endpoint returns challenge
  5. User returns to RP website
  6. RP website receives DC credential response, including a response to the PoA challenge

Are there other feasible solutions?

Note this will likely be relevant to ARF discussion topic C.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Doing
Development

No branches or pull requests

1 participant