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