That's a much better place to communicate redaction reasons.
Although if the use case for communicating secured redaction reasons from
the holder to the verifier doesn't fit well with SD-JWT spec, it's possible
that's a profile specific thing, where interoperability matters less, so it
should be covered in another document.
And again, I tend to agree that this could lead to poor holder hygiene, and
"over sharing"... even issues where the holder accidentally reveals the
redacted claim, in their awkward attempt to provide a reason for its
redaction.
Perhaps an allow list / registry approach would be better than allowing
free form responses from the holder.
OS
On Fri, Oct 20, 2023 at 9:30 AM Daniel Fett <m...@danielfett.de> wrote:
> 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>
>> <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>
>
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
