Updates to proof syntax

[tplooker]

This PR updates the following

• renames proof to proofValue as per a suggestion made by @dlongley and @msporny, captured in Use proofValue as the the value for the proof #25
• removes revealedIndicies and totalStatements as this information is going to be embedded into the proofValue now following the proposal in Revealed statements representation #22

Fixes #25, Fixes #22

[msporny]

LGTM -- solid direction... thank you!

[kdenhartog]

What’s the order of which the bytes are being concatenated in the proofValue? I didn’t see a mention of that in there, but might have just missed it.

[tplooker]

@kdenhartog our intention at this stage is to not define that in this spec but instead in the IETF draft for BBS signatures and then point this spec at that.

[dlongley]

LGTM!

[dlongley]

@tplooker -- would the other tweak we discussed: expressing 2-tuples of (blank node ID/index from full data, blank node ID/index from disclosed data) to eliminate the need for special skolem URIs (urn:bnid:<stuff>) also just fall under the IETF draft?

[tplooker]

@dlongley, was just about to document that idea you suggested in #10, r.e where the BN mapping algorithm should live, IMO right now I would say the definition of that algorithm would still be in this spec (or a section of the linked data proof spec?) as it is an algorithm that is applied specifically to preparing the "verify data" for a linked data proof. Different assertion formats such as JWS CWS would perhaps not have the concept of this type of mapping? Essentially the proposed crypto API for verifyProof is

verifyProof({
publicKey,
proof,
verifyData,
challenge
})

E.g here is a little runnable sample of a reference implementation https://github.com/mattrglobal/node-bbs-signatures#usage

[dlongley]

@tplooker -- ok, sounds good.