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

Challenge and nonce with DIF PEX #198

Open
TimoGlastra opened this issue Feb 7, 2024 · 7 comments
Open

Challenge and nonce with DIF PEX #198

TimoGlastra opened this issue Feb 7, 2024 · 7 comments
Assignees

Comments

@TimoGlastra
Copy link
Member

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
Copy link
Member Author

Cc @swcurran @tra371 @gvelez17

@auer-martin
Copy link

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
Copy link
Member Author

Sounds good to me!

@swcurran
Copy link
Member

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
Copy link

auer-martin commented Feb 13, 2024

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
Copy link
Member

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
Copy link

I think that's all. 👍🏻

@swcurran swcurran self-assigned this Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants