Hello!
I a one of the editors, feel free to ask questions.
I a one of the editors, feel free to ask questions.
JWP (JSON Web Proofs) are meant to provide for privacy. I'll give an example of digital documents used as credentials.
Imaging a health record containing your vaccination history. This could be signed and shared as an interchange record between doctors. It could also be used as a proof of vaccination - this is what SMART Health Cards were.
However, there is considerable information in those records that I may not want to share - not just that I _was_ vaccinated for instance, but when and where, by whom, from which batch, potentially under what insurance. It is also common to have personal information like full name and potentially home address.
So you may want the ability to select which information is disclosed - you can do this with traditional signature and hashing algorithms by building a Merkle tree or nesting signatures with ephemeral keys. The document still has integrity, but only some subset of the information has been shared.
The signatures and hashes from a classic algorithm serve as potentially trackable identifiers as well. Newer algorithms like BBS provide unlinkability, where presentation of the same source document multiple times does not allow for parties to correlate my usages.
Finally, you also may want to disclose derived information - such as just that I have a vaccination in the last x months, rather than the precise date or location, or just that I'm of legal age to purchase alcohol in my country, rather than my birthdate. These sorts of predicate proofs are also of interest to the group, although the algorithms and representations aren't as far along yet.
That sounds kind of crazy. I can't imagine how you'd prove derived data. Very cool though. Thanks!
Cryptocurrencies seemed to accelerate the revision, implementation and deployment of newer cryptographic techniques. Range proofs are used in that space to obscure transaction amounts, using techniques like bulletproofs.
A more primitive but easier example to understand would be a hash chain, https://en.wikipedia.org/wiki/Hash_chain.
The issuing authority signs a hash of some shared secret seed value x times, where x is my age. If I want to prove I'm over 18, I hash the seed value x - 18 times and give it along with the signed hash. The verifier hashes it 18 times to get the signed value and thus knows I'm "at least" 18 years old.
If I include a second hash of 150 minus my age, I can use that to disclose that I'm under a certain age as well. Together, I can establish an age range.
Range proofs will really loosen the amount of design consideration you need to make when creating credentials with strong privacy considerations.
For example, even processing metadata like expiry times for a credential leaks correlatable information, unless you take additional care. The renewal date for a corresponding physical document may be spread out evenly over the year and often stays consistent, so the expiry time of the physical document might divide people into one of 365 groups without some (potentially painful) additional considerations.
A range proof instead would say 'the current is within the validity period of the document'.
At the extreme this gets to verifiable computation, where I can verify that an output was created from an input document and a set of instructions. However, I can do so without seeing the input document. With this, you could externalize the entirety of processing, and rather than getting personal information back get a message saying "yes this meets your policy".
After quickly skimming these drafts, I can’t tell whether it’s fixed. Certainly a lot of algorithm names are sprinkled around the encoded objects, but I didn’t spot a description of what a public key is.
I am moderately concerned by statements like:
6.3.2. Issuer Setup To use the MAC algorithm the issuer must have a stable public key pair to perform signing. To start the issuance process, a single 32-byte random Shared Secret must first be generated. This value will be shared privately to the holder as part of the issuer's JWP proof value
Few if any cryptosystems are intended to be secure if the private key is used in the wrong algorithm. This paragraph reads like one party should, as part of the API used by the application, one party sends 32 bytes, char[32]-style, to another. I don’t think any new design should work like this. New designs should fail hard when misused or when parties disagree as to what protocol variant they’re speaking.
Is there something in here to make the new standard clearly immune to algorithm confusion attacks?
Right, and I believe this is one of the major misconceptions about JOSE - it isn't defining a data format for secure messages, but common tooling/patterns to be profiled for applications needing secure messaging.
This leads to a confusion of responsibilities between a JOSE library and the application using it.
So we are watching / participating in efforts like https://www.ietf.org/archive/id/draft-tschofenig-jose-cose-g... and https://www.ietf.org/archive/id/draft-ietf-httpbis-message-s... .
I'm hoping there is stricter guidance across the board by the time JWP goes to publication.