Challenge and nonce with DIF PEX

[TimoGlastra]

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-format

However 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 nonce

In 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:

    const hash = Hasher.hash(TypedArrayEncoder.fromString(challenge), 'sha-256')
    const nonce = new BigNumber(hash).toString().slice(0, 32)

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

[TimoGlastra]

Cc @swcurran @tra371 @gvelez17

[auer-martin]

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)

[TimoGlastra]

Sounds good to me!

[swcurran]

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 from DIF PEX MUST be used as the nonce in an AnonCreds Proof.
• 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?)
• The both the holder (on receipt of the presentation request), and the verifier (on receipt of the presentation, from the presentation request 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?

[auer-martin]

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.

• 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.)
• 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)
• both the holder (on receipt of the presentation request) and the verifier (on receipt of the presentation, from the presentation request challenge value) MUST carry out this operation. (Yes, both need to derice the same value 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.

[swcurran]

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?

[auer-martin]

I think that's all. 👍🏻