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
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:
prover shares commitment involving the right keys
verifier shares challenge
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:
RP website shares DC credential request, including an RP PoA-HTTP endpoint
User authenticates to WSCA
WSCA shares commitment at PoA-HTTP endpoint
PoA-HTTP endpoint returns challenge
User returns to RP website
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.
The text was updated successfully, but these errors were encountered:
To meet the ARF Topic 18 requirements, we need a proof of association (PoA) method that is:
This will require three protocol steps:
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:
Are there other feasible solutions?
Note this will likely be relevant to ARF discussion topic C.
The text was updated successfully, but these errors were encountered: