# Reconsilation Possibility for SD-JWT and JWP Proposals

## Issuer creation:
The issuer general several pieces of data

e.g. base JWT payload, data to make selectively disclosable

Generating releasable payloads:

For each value:

Generate random salt, create JSON text for salt, key and value (which can be any valid JSON structure):

[ "salt", "key", "value"]"

This UTF-8 text is then hashed, to `abcd1234…`

You then add these hashes to a base payload:

{
//  "sub", "iss", "exp", "etc",
  "disclosable_payload_hashes": [
      "abcd1234...",
      "defg1234..."
  ]
}

You add a header parameter to indicate this is a sd_jwt along with a `crit` for that header.

You create a JWT based on the base payload in the normal mechanism, e.g.

b64(header).b64(base_payload).b64(sig)

After that, you append each releasable payload to the base64-encoded base_payload, in order of hashes in base payload, delimited by tildes.

b64(header).b64(base_payload)~b64(releasable_payload_1)~….signature

On receipt:
===
Client receives the base JWT message along with all disclosable payloads. Note that some of the payloads may not exist - an issuer is allowed to 'make up' a value so that it might confound verifiers who might try to correlate based on the number of payloads any particular user might have.

Remove characters from the first tilde to the following period to convert to a JWT which can be validated via a standard library.

Hash each tilde-delimited payload and compare to each disclosable_payload value to verify the payloads are correct.

To selectively disclose:
===
For the received SD-JWT, remove any disclosable payloads which you do not wish to disclose from the message text. This may result in sequential delimiter characters, such as two tildes next to one another.

Presentation proofs:
===
This is difficult, because we don't want to require certain features which JWT libraries might not already have.

For the selectively disclosed (filtered) version of the issued message:

b64(header).b64(base_payload)~b64(releasable_payload_1)~….signature

You would use this value as the _payload_ of a new JWT from the holder, signed with the payload key

b64(holder_header).b64(above_filtered_sd_jwt).b64(holder_signature)

However, you would substitute the non-base64-encoded version for the base64 version after hashing (split on lines for readability):

b64(holder_header).
b64(header).
b64(base_payload)~
b64(releasable_payload_1)~
….
b64(signature).
b64(holder_signature)

This operation exists solely to reduce an unneeded size increase from unneeded base64 URL encoding.

Verification:
===

The verifier will take the value between the first and last dots and verify it based on the holder rules above.

It will then take that data and base64-encode it, converting the message back to:

b64(holder_header).b64(filtered_sd_jwt).b64(holder_signature)

Which will validate as a JWT signed by the holder.