Hello,
In government documents that feature redaction, it's common for the
redaction to be given a reason.
For example, in the Mueller report, we can see "Harm to Ongoing Matter",
"Personal Privacy", "Investigative Technique", as well as "IT" and "HOM".
In SD-JWT we see the following:
Case 1
"_sd": [
"IjCRF...znc", // disclosure hash
"Qdpt9pL...lhU9UDo" // disclosure hash
]
and
Case 2
{ "...": "Qdpt9pLE2-MjCr...IzhZlhU9UDo" // disclosure hash }
After verification and applying disclosures these annotations are no longer
present.
I wonder if it would be worth allowing a reason for why a holder might have
retained a redaction (or chose not to disclose for a reason).
Since the payload is committed to by the issuer, this information would
have to be present in the disclosures collection for the SD-JWT.
Here is an example disclosure:
[
"8UbQ9NZ6xseoDqMW_Bd50A", // salt
"type", // json object key (always a string)
[ // json object value
"VerifiableCredential",
"ExampleAlumniCredential"
]
]
Consider the following strawman syntax for disclosing a redaction reason:
{
"disclosure hash" : "Personal Privacy" || "Harm to Ongoing Matter"
}
This allows a UI to map the redaction reason into a presentation (ui) layer
for the issuer secured payload.
Since it's an unsecured object, it can be extended with other fields at the
discretion of the holder or issuer.
However it might be secured by nesting it inside another JWT or SD-JWT.
It would only slightly complicate the verification logic, you would need to
filter any encoded disclosures by the `ey` prefix, since they will never be
found in the payload, as we know they will hash differently than array
encoded disclosures, which will be found in the payload.
I'll be giving a presentation on this topic to the W3C Credentials
community group later today, happy to shuttle their reactions back to this
list.
Apologies if this has been discussed previously.
Regards,
OS
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
