[Privacy] Anonymous claims

[peppelinux]

Problem

A user doesn't want to show which attributes he got from an issuer in a VC. The reason behind this is that the user doesn't want to give to a RP any information about the attributes that this RP may ask to him in the future. If a RP has a proof of possession of some claim of a user it may ask these to the user, in the future, producing some reason, some levers or circumstances, to persuade a need to the user to share his claims to the RP.

A RP may know that a user is also:

• graduated even without knowing the value contained in the related claim.
• married, without knowing the attributes of the spouse
• and so on ...

This means that the only presence of a claim, even if its value is opaque, can determine an information or a proof of truth. This scenario is not relevant for a person schema (eIDAS minimum data set) but can be relevant with the issuing of some extendend attestation of the personal attributes.

Requirement

A way to make also the claim names anonymous/opaques.

Current behaviour

The sd_digest shows how many and which attributes the user may disclose

...
  "sd_digests": {
    "sub": "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",
    ...
  }
...

Expected behaviour

Also the claim names can be obscured, defining an additional structure type to the current three available to date (simple, structured, complex). The result can be the SD-JWT in the example given above

{
  "iss": "https://example.com/issuer",
  "sub_jwk": {
    "kty": "RSA",
    "n": "pm4bOHBg-oYhAyPWzR56AWX3rUIXp11_ICDkGgS6W3ZWLts-hzwI3x65659kg4hVo9dbGoCJE3ZGF_eaetE30UhBUEgpGwrDrQiJ9zqprmcFfr3qvvkGjtth8Zgl1eM2bJcOwE7PCBHWTKWYs152R7g6Jg2OVph-a8rq-q79MhKG5QoW_mTz10QT_6H4c7PjWG1fjh8hpWNnbP_pv6d1zSwZfc5fl6yVRL0DV0V3lGHKe2Wqf_eNGjBrBLVklDTk8-stX_MWLcR-EGmXAOv0UBWitS_dXJKJu-vXJyw14nHSGuxTIK2hx1pttMft9CsvqimXKeDTU14qQL1eE7ihcw",
    "e": "AQAB"
  },
  "hash_alg": "sha-256",
  "iat": 1516239022,
  "exp": 1516247022,
  "sd_digests": [
    "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04",
    "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs",
    "9h5vgv6TpFV6GmnPtugiMLl5tHetHeb5X_2cKHjN7cw",
    "fPZ92dtYMCN2Nb-2ac_zSH19p4yakUXrZl_-wSgaazA",
    "QdSffzNzzd0n60MsSmuiKj6Y6Enk2b-BS-KtEePde5M",
    "JFu99NUXPq55f6DFBZ22rMkxMNHayCrfPG0FDsqbyDs",
    "Ia1Tc6_Xnt5CJc2LtKcu6Wvqr42glBGGcjGOye8Zf3U"
  ],
  "hash_alg": "sha-256"
}

The related SVC could be as follows

{
  "sd_release": {
    "LbnhkOr5oS7KjeUrxezAu8TG0CpWz0jSixy6tffuo04": {"claim": "sub", "value": "6c5c0a49-b589-431d-bae7-219122a9ec2c", salt: "eluV5Og3gSNII8EYnsxA_A"},
    "fUMdn88aaoyKTHrvZd6AuLmPraGhPJ0zF5r_JhxCVZs": {"claim": "given_name", "value": "John", "salt": "6Ij7tM-a5iVPGboS5tmvVA"},
...
  }
}

[danielfett]

Would that work well with structured claims, like the eKYC example?

[danielfett]

You write

defining an additional structure type to the current three available to date (simple, structured, complex).

Just to ensure that we're all on the same page: These three are not defined in the spec and are not intended to be. There is just one type, it just so happens that the 'flat' structure will probably be a common use case. It is therefore used in Example 1. But it is really just a special case of an essentially arbitrary JSON object.

[peppelinux]

For the structured claims we can adopt the same approach, exposing only the hashed values pointing to a json object that defines salt, value and claim name

in other words, the new sd_digest array should be flat

[danielfett]

If sd_digests is always flat, I assume that the 'structure' is reconstructed from the SD-JWT-R, where the holder uses parts of the structure from the SVC. In this case, how would you prevent a holder from tampering with the structure, e.g., moving a claim to a different part of the structure or creating a whole new structure?

[peppelinux]

yes, I wonder on the possibile approaches, please add your thoughts. Regarding the structure:

1. Abandon JSON Object to embedded JWT. This proposal seems to be declined here. so, let's look forward.

2. define a rule, in the specs, about how the serialization of the json object must be done. No additional spaces and alphabetical ordering of the entries.

AFAIK a SD-JWT is signed by a trusted issuer and is tamper proof. SD-JWT-R is released and optionally signed by a Holder. The Holder in SD-JWT-R uses the sd_digests taken from SD-JWT. The hash_alg is not per claim but is globally defined in the SD-JWT. If I understand well the Holder can't tamper the salt or the digest or the hash alg, for each claim.

Needs discussion. Consider me available for the implementation of a PoC to stress out all the possibile weakness of this proposal

[danielfett]

I'm not sure if I'm following. I think it would be good if you could show an example of what a structured SD-JWT, SVC and SD-JWT-R would look like.

[peppelinux]

Closed by https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/106