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>
> <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 STEELE Chief Technology Officer www.transmute.industries
>>
>> <https://transmute.industries>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://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 STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
