[OAUTH-WG] Re: We cannot trust Issuers

[Watson Ladd <[e-mail]>]

As said I offer it as a starting point. There might be some value in
the existing text, but I found it distracted from clear presentation
of the problem. What's the problem with using MUST? We have to give
people who use these documents clear guidance.

I think the tautology is obvious: if SD-JWT doesn't offer the property
X that is required, it MUST NOT be used when X is required. and that's
exactly what should appear.

On Wed, Jul 31, 2024, 4:58 PM Brian Campbell <[e-mail]> wrote:
>
> I guess I had envisioned suggestions that didn't delete a bunch of existing valuable and useful text. Rather I was expecting (or maybe just hoping) for thoughtful suggestions adding to what's already written that, as I'd said, better frame the risks and difficulties around Issuer/Verifier Unlinkability (perhaps especially with respect to something like a government issuer compelling collusion from verifiers). I'm also not a big fan of broad strokes RFC 2119 language in privacy considerations.
>
> On Wed, Jul 31, 2024 at 11:31 AM Watson Ladd <[e-mail]> wrote:
>>
>> I've opened https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/448
>> as a step torwads this.
>>
>> On Wed, Jul 31, 2024 at 5:31 AM Brian Campbell
>> <[e-mail]> wrote:
>> >
>> >
>> >
>> > On Tue, Jul 23, 2024 at 11:15 AM Leif Johansson <[e-mail]> wrote:
>> >>
>> >> On Mon, 2024-07-22 at 19:43 -0400, Richard Barnes wrote:
>> >> > I would observe that any solution based on garden-variety digital
>> >> > signature (not something zero-knowledge like BBS / JWP) will have
>> >> > problems with issuer/verifier collusion.  One-time tokens and batch
>> >> > issuance don't help.  There is no such thing as SD-JWT with
>> >> > issuer/verifier collusion resistance.  At best you could have SD-JWP.
>> >> >
>> >> > I don't think this needs to be a blocker on SD-JWT.  There are use
>> >> > cases that don't require issuer/verifier collusion resistance.  We
>> >> > should be clear on the security considerations and warn people away
>> >> > who care about issuer/verifier collusion resistance, and accelerate
>> >> > work on SD-JWP if that's an important property to folks.
>> >> >
>> >>
>> >>
>> >> +1 on this
>> >
>> >
>> > I'm generally a +1 on this too.  There is an attempt at a discussion around unlinkablity in the privacy considerations at https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-10.html#name-unlinkability currently. Concrete suggestions to that text about how to better frame the risks and difficulties around Issuer/Verifier Unlinkability (perhaps especially with respect to something like a government issuer compelling collusion from verifiers) would be welcome for consideration.
>> >
>> > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.