The Holder can put such information into the KB-JWT, if required.
-Daniel
Am 20.10.23 um 16:28 schrieb Orie Steele:
In some ways this is related to the question about disclosures.
On Fri, Oct 20, 2023 at 9:03 AM Daniel Fett
<fett=40danielfett...@dmarc.ietf.org> wrote:
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.
I tend to agree with the latter.
There is substantial security / privacy risk, making disclosures carry
ANY information other than what the issuer committed to.
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.
This assumes the issuer knows why the holder chose not to disclose a
field.... For some use cases that's probably a knowable thing... it
also prevents the holder from using the disclosures as an unsecured
channel to communicate with the verifier.
-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> <mailto: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
<http://www.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
--
ORIE STEELEChief Technology Officerwww.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
