At least at the moment I don't think that there is a huge need for such
a feature. I don't think that we should clutter the existing SD-JWT data
structures with such information.
If required, it could go into a separate data structure in the SD-JWT,
for example a list of JSON pointers with a mapping to the respective
redaction reasons.
-Daniel
Am 18.10.23 um 05:03 schrieb Tom Jones:
That's leaking the existence of PII. That requires permission of the
subject. I think it's way more complicated than you think.
thx ..Tom (mobile)
On Tue, Oct 17, 2023, 6:20 AM Orie Steele <orie@transmute.industries>
wrote:
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 STEELEChief Technology Officerwww.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Please use my new email address:m...@danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
