Open TimoGlastra opened 6 months ago
Cc @swcurran @tra371 @gvelez17
I think this is a mistake. According to the spec, the output needs to be 80 bits long. Perhaps it is cleanest to always do it this way, rather than dealing with cases where the challenge is not a number or not long enough in a particular way.
const hash = Hasher.hash(TypedArrayEncoder.fromString(challenge), 'sha-256')
const nonce = new BigNumber(hash).toString().slice(0, 20)
Sounds good to me!
I think I get the issue, but I’m not sure what is impacted by this. Is it a convention that the verifier and the holder must implement independently (and so is only defined in the spec.) or is it something we can/should put into anoncreds-rs?
challenge
in the DIF PEX meets the AnonCreds nonce requirements (right?)challenge
value) MUST carry out this operation.Should we add an anoncreds-rs difpex-challenge-to-nonce
method? Not sure it helps as it still has to be invoked by the respective libraries.
Am I getting it?
Based on the presentation definition and submission, we must create an AnonCredsProofRequest. This step is done manually on top of AnonCreds-RS, and the AnonCredsProofRequest is required to create and verify the signed presentation. The problem is that we need a deterministic nonce for the AnonCredsProofRequest. Verification fails if the holder and verifier use different values for the nonce.
I don't think difpex-challenge-to-nonce
helps a lot (Just my opinion). But it is an option.
Hope this helps.
The requirement is that the holder and verifier use the same nonce. What I was proposing were rules that we define (specify) so that the requirement is met. I agree that there are other ways we could do it, but that just means we define different rules that haven’t be specified. My comment above was to codify what (based on your guidance) is the best option:
Challenge from DIF PEX MUST be used as the nonce in an AnonCreds Proof. (No, but the holder/verifier must use the same value. But I am not sure how many good alternatives we have, using the challenge just seems like a good option.)
I agree that the challenge is a good option, and should be the one we choose. Hence the rule.
The challenge MUST be converted into the nonce as described above, even if the challenge in the DIF PEX meets the AnonCreds nonce requirements (right?). (No, but I think in most cases the challenge won't meet the quite strict requirements for the nonce thus, it may be simpler always to do the transformation step)
If we don’t require that the challenge be converted every time, then the holder (and verifier) have to check to see if the challenge meets the nonce requirements (using the same definition of the requirements) and decide to convert it or not. Seems much easier and safer to just say “convert it every time”.
So those are two rules that MUST be followed by the holders and verifiers to ensure alignment.
Am I missing something?
I think that's all. 👍🏻
When transforming a DIF Presentation Definition/Submission into an AnonCreds Proof Request we need to provide a
nonce
.When proving a W3C AnonCreds VP we can take the
challenge
field from the presentation request message: https://github.com/hyperledger/aries-rfcs/blob/main/features/0510-dif-pres-exch-attach/README.md#request-presentation-attachment-formatHowever a nonce for AnonCreds must be a 32-byte number I think. I think we may need to define that the
challenge
MUST be used as the nonceIn addition I think we may need to loosen up the restrictions for a nonce in AnonCreds, or maybe we can define that if the nonce is not a 32-byte number you can hash the nonce, and then take the first 32 bytes of that number (a bit like how anoncreds credential value encoding works)
An implementaiton in Credo by @2mau:
I think we could define this in the AnonCres spec, and also implement in this in AnonCreds RS. Otherwise if you want to allow a DIF PEX to result in an AnonCreds credential you ALWAYS must use 32 byte long numbers as nonce, just for maybe AnonCreds being involed in the presentation