add nonce option to DeriveCredential API

[troyronda]

No description provided.

[troyronda]

If we want to be able to generate a nonce, we might need a bit more nuance in this description or another option.

I tend to think we should just have the client pass in the nonce.

Note: I kept this description similar to the challenge option.

[troyronda]

To make the default less ambiguous, we can either state that the default is to generate a nonce or that the default is empty nonce.

In the case where the default is a generated nonce, we would also want to specify the behavior of an empty nonce option being provided.

Note: the BBS+ Signatures spec currently states:

A linked data document featuring a BBS+ proof of knowledge linked data proof MAY contain a nonce attribute.

[OR13]

another example of harmful MAY... why is this not a MUST and be of min length ... etc... @tplooker can we make this a MUST ?

[OR13]

w3c/vc-di-bbs#43

[troyronda]

As we need to include the nonce bytes into the proof, perhaps we should specify that the nonce option is base64 encoded. @tplooker @OR13

[msporny]

As a general rule these days, if you catch your self picking a base-encoding format, you're probably wrong. :)

A few things to keep in mind:

1. Multibase exists, if you want to base-encode something, we should use multibase for the value.
2. Protocols can limit the type of base-encoding used (e.g. base58btc only). It's the easiest way to not get locked into a base encoding that doesn't work for some subset of the community.
3. The nonce value should never be optional and never be "default empty" in a protocol that is susceptible to replays. I think I saw something to this effect in a PR that flew through my inbox... just noting that it'll be a hard objection from us if folks want to default to empty nonces.

That said, the nonce value being encoded as pure bytes really doesn't matter... don't think we need to base-encode it... you just need enough randomness to prevent replays... and you can do that w/ just UUIDs or ASCII characters. If folks have a "but I want to run this protocol over a compressed binary stream" use case, we could say that nonce needs to be multibase encoded in /this particular protocol/.

[troyronda]

@msporny

Multibase exists, if you want to base-encode something, we should use multibase for the value.

The context for mentioning base64 (or encoding, in general) comes from the BBS+ Signatures implementations and spec examples using it. As the nonce output uses encoded bytes, I was curious if the input should be encoded so they end up being the same.

I agree that multibase is good.

The nonce value should never be optional and never be "default empty" in a protocol that is susceptible to replays.

Yup. In this case the output is a derivation of the VC (and is, itself a VC), but I would imagine the common intention is to use the derived VC once. @OR13 has opened a PR on the BBS+ Signatures spec regarding the MAY vs MUST nonce topic (w3c/vc-di-bbs#43).

That said, the nonce value being encoded as pure bytes really doesn't matter

Note: the holder and the verifier both include the pure bytes into their proof computation. The output BBS+ LD Proof nonce property uses encoded bytes.

Example from BBS+ Signatures spec:

"nonce": "6i3dTz5yFfWJ8zgsamuyZa4yAHPm75tUOOXddR6krCvCYk77sbCOuEVcdBCDd/l6tIY="

Of course, the derive service can transform from the input to bytes for the proof computation and do the output encoding for the nonce property. (and, as currently described in this PR: this is what would happen).

[OR13]

@tplooker I agree with this thread, and am bothered by the base64 use in that suite :) we should move to multibase in the next version.

[OR13]

This is spec only, and limited support for it in the test suite, propose we merge before cut, since its already an optional API.