nonce property

[tc-developer01]

Hello,

we are trying to implement Verifiable Credentials and Verifiable Presentations using JWTs as well as JSON-LD & BBS+, and there is some confusion about the nonce property.

In examples #28 (VC) and #31 (VP) in the spec there is a nonce field present inside the JWT – but no further mention of the nonce property elsewhere in the spec (or the JWT Wikipedia page).

Where can we find more information about the meaning of the nonce field and whether it is optional or not, and what the intended use case for the nonce field is, especially in regards to the challenge & domain property?

When creating BBS credentials using the mattrglobal/jsonld-signatures-bbs library, there is only one case where a nonce is included in the proof property:

• Verifiable Credential
• Verifiable Presentation
• Derived Credential (Selective Disclosure / Proof of Knowledge)

This complies with the BBS spec, which states that a proof must contain a nonce when featuring a proof of knowledge.

So, I think I can summarize my question as follows:

• What is the general purpose of a nonce?
• How does it interact with the challenge/domain part?
• Can you use a nonce in a Verifiable Credential?
• Must you use a nonce in a Verifiable Credential?
• Can you use a nonce in a Verifiable Presentation?
• Must you use a nonce in a Verifiable Presentation?
• Why must you use it when using Selective Disclosure via BBS+?

Thank you very much!

[dlongley]

What is the general purpose of a nonce?

To either prevent replay attacks, prevent undesirable correlation, or as a component in puzzle solving (such as PoW). There may be other uses. It is a value that is intended to only ever be used once.

A challenge is different from a nonce in that a challenge carries with it the semantics that it is a part of a challenge-response authentication mechanism and that the challenge value is always set by the relying party (or "verifier"). A nonce may be used as a challenge in such a protocol, but using challenge to describe such a value is preferable because it is more clear. A nonce, depending on the protocol, may be set by the "client"/"prover"/"holder"/"presenter" as opposed to the relying party or "verifier".

Can you use a nonce in a Verifiable Credential?

How a nonce is used depends on the type of proof. For example, a BBS+ nonce is not used as a challenge but to introduce randomness into a derived credential proof. Someone else like @tplooker could comment more on this.

How does it interact with the challenge/domain part?

In the usage I've seen, they are unrelated. The challenge/domain are included in authentication proofs on Verifiable Presentations and nonce is used in, for example, BBS+ derived credential proofs that do not include domain or challenge. There may be a mode to include domain in a derived credential proof for some method of binding / avoidance of reuse, I don't know. Again, that's not a question that I can answer at this time.

Must you use a nonce in a Verifiable Credential?

No.

Can you use a nonce in a Verifiable Presentation?

Yes, this depends on the type of proof(s) that are supported. Some proofs may use a nonce in a VP, but I'm not aware of any at this time, but there is nothing that says someone can't invent a proof that has a need for a nonce.

Must you use a nonce in a Verifiable Presentation?

No.

Why must you use it when using Selective Disclosure via BBS+?

I would defer to @tplooker or @kdenhartog to give you a more robust answer here.

[dmitrizagidulin]

@dlongley great explanation! I think we need to add some of this wording into the spec itself.

[iherman]

The issue was discussed in a meeting on 2021-10-06

• no resolutions were taken

View the transcript

2.1. nonce property (issue vc-data-model#823)

See github issue vc-data-model#823.

Brent Zundel: This link should give us any issues not marked with a ... label

Kyle Den Hartog: I'm not certain... we brought up an issue on BBS+, planned to link to it but couldn't find it...
… I will link to that. +1 to dmitriz's suggestion... not sure though because nonce is related to proof property - need to double-check on specificity, for specific suites...
… could result in additional text

Dave Longley: I think they are largely asking questions - but ultimately about a property that is not part of the VC data model - it's part of the proofs
… When VCWG recharters ... we might cover this, or defer to other specs

Dmitri Zagidulin: We do mention challenge in the Verifiable Presentation section.
… Unless I'm looking at the wrong version and we took it out...
… I'm wondering if that might be the place to contrast challenge and nonce.

Brent Zundel: We had a similar issue in the Presentation Exchange spec...

Dmitri Zagidulin: or maybe it would be good to add language to the VC Implementation guide?

Dmitri Zagidulin: ohhh, this is the section I meant. It IS in the implementation guide https://www.w3.org/TR/vc-imp-guide/#presentations

Brent Zundel: https://identity.foundation/presentation-exchange/#presentation-request

Brent Zundel: We recognized that alongside the presentation definition object, a verifier might want to specify the challenge or nonce. We put some generic language there, that might be appropriate here

Dave Longley: We could certainly put something informative in the spec... but I don't know if that would resolve this person's issue... they are looking for something more concrete...
… We are looking to add that to the next charter, with specific details.

Kyle Den Hartog: This would require changes to the context, which we've traditionally declared defer-v2
… I think we should defer it, not a handwavy approach
… It is close to authentication protocols - might need to put that in scope - but more controversial - in the charter

Dave Longley: +1 to defer v2 and question labels

Kyle Den Hartog: +1

Brent Zundel: Label "defer v2"" and "question"?
… [Describing the resolution for David and Juan who just joined the call]

[brianorwhatever]

I think there is some confusion here as I just stumbled on this myself. I believe what is catching the OP and myself is that the JWT encoding of a VC mentions a nonce in the payload whereas with Linked Data proofs the nonce would be included within the proof. My best guess as for why this would be the case is that the JWT variant, at this point, uses a standard JWS which doesn't include a nonce property so this must be moved into the payload. Please correct me if my understanding is off..

[David-Chadwick]

My feeling is that the examples have simply included a nonce by mistake and they should be removed. There is no description of them in the text and they serve no purpose in the examples - except to confuse the reader.

[clehner]

May I mention, the nonce JWT claim could be used in an analogous way to the challenge proof property, in JWT VP, i.e. as part of a challenge-response protocol, to prove liveness. In JWT VC this may be less useful, as I understand VCs are not so much intended to be created in a challenge-response protocol like VPs would be.

There is an implementation of JWT VCs/VPs using DID issuers, that explicitly uses the nonce JWT as analogous to the challenge proof property, here: decentralized-identity/did-jwt-vc#60 (Additionally, that is using the aud JWT claim as analogous to the domain proof property). Spruce's JWT VC/VP implementation (https://github.com/spruceid/ssi/blob/8849c0ce5f4d220c1784db5427d2661e40af3cd6/src/vc.rs#L1381) follows this usage as an API convention. I note the difference in meaning as described by @dlongley in #34, that nonce does not as much imply a challenge-response protocol; but I suppose it was considered (in DIF's did-jwt-vc project) as close enough, as far as registered JWT claims names go.

As for the nonce property in proof objects, I see it is in the JSON-LD context for the proof types in the Credentials v1.0 base context. In practice I don't see it is used in those proof types as specified. There are implementations using nonce with the unspecified EcdsaSecp256r1Signature2019 proof type, however, as seen in these VCs:

• https://github.com/Consensas/jsonxt/blob/dffa643c49e433cdc4b16305c2a61377cbb2981f/data/ibm-1-2.json
• https://github.com/elmariachi111/ultimate-non-infectious-verifier/blob/3e2be1b736c84a91018069b2c6f21789a3bf3286/docs/samples/vacc_credential_hp_ibm.json

BbsBlsSignatureProof2020 uses the proof nonce property, as has been mentioned: https://w3c-ccg.github.io/ldp-bbs2020/#nonce
MerkleProof2019 also uses it, in an example at least: https://w3c-ccg.github.io/lds-merkle-proof-2019/#example-3

[Sakurann]

nonce included in VC/VP ties VC/VP to an issuance/presentation transaction. So how to use it is out of scope of vc-data-model and is defined in other specifications, for example, OpenID4VP. Suggest to close this issue on that ground.

[TallTed]

[@Sakurann] nonce included in VC/VP ties VC/VP to an issuance/presentation transaction. So how to use it is out of scope of vc-data-model and is defined in other specifications, for example, OpenID4VP. Suggest to close this issue on that ground.

If nonce is still included in one or more example(s) in the updated VCDM doc, I think it's worth also adding some prose to the above effect into the updated doc, if such has not been added yet.

[iherman]

The issue was discussed in a meeting on 2022-07-27

• no resolutions were taken

View the transcript

5.1. nonce property (issue vc-data-model#823)

See github issue vc-data-model#823.

Brent Zundel: kristina and I marked it as pending closed bc we think it maybe has been dealt with but TallTed made a comment recently....

Manu Sporny: I don't think we can close this. It comes into the data integrity and VP side. It's on the edge of protocol, but I don't think we can close it.
… It's likely to end up the Data Integrity spec.

Ted Thibodeau Jr.: I'm mostly fine with that. If we're still including Nonce in the examples the we should say why it's still here, go see the spec over there.

Brent Zundel: I'll remove the pending closed tag and make it DI?.

Kristina Yasuda: I would say it will go in the JWT VC spec too.

Brent Zundel: I can add those labels.

Manu Sporny: yeah, +1 it should be mentioned in JWT-VC spec as well..

David Chadwick: I did add some text into the data model 1.1 so there is some text there talking about the nonce that wasn't in 1.0, but more detail needs to go into the v2 spec.

Manu Sporny: Fundamentally, challenge is provided by the server... domain and nonce are provided by the client.

David Chadwick: but if examples are being pulled out then the text will also go.

Brent Zundel: I will add the labels.

[msporny]

The VC Data Integrity specification no longer defines nonce. The Security vocabulary has marked it as deprecated.

That is the current state of the specifications, and that does not line up with the conversations above.

It looks like the only entity using nonce at present is BBS. Does the BBS cryptosuite continue to need the nonce value?

[Sakurann]

But data integrity spec has "challenge" that is equivalent to JWT "nonce" claim, correct?

[msporny]

But data integrity spec has "challenge" that is equivalent to JWT "nonce" claim, correct?

I'm not sure it's entirely equivalent as the use of "nonce" seems to be wrapped up in OpenID token semantics. With a little hand waving, you could say they're similar.

In Data Integrity, a challenge is typically provided by a party that wants to receive data from another party (server) and is included and signed over by the other party (client) in their response. From what I understand, there is further binding that the server does with a client session where the client doesn't have to do anything w/ the nonce value. That's where things start deviating.

[msporny]

Marking this as pending close because the Data Integrity specification no longer specifies a nonce value, and if BBS needs the value, it can specify it directly or open a new issue on this repository. I will also note that @awoie has mentioned wanting something like a nonce value, but if that's the case, we'll just have to open a new issue that requests that the value is added back into the specification.

[farwayer]

To be honest, the specification about challenge and nonce is not very clear. There are no examples of how and in what case each field should be used.

Challenge, as far as I understand, can be repeated in a timeframe. In what practical cases can this be useful compared to generating a unique challenge for each signature? By randomly generating a challenge each time, the nonce field becomes unnecessary.

Challenge sounds like something that should be used in request-response interaction. Then the response should include the same challenge that was in the signature request. Is this a correct use of challenge? But then it should not be repeated even in a short timeframe.

We are implementing a complex protocol with the transfer of signed messages, sometimes it is request-response. And we are confused about how to use these fields correctly.