[OAUTH-WG] Re: We cannot trust Issuers

[Michael Prorock <[e-mail]>]

+1 Richard

Mike Prorock
Founder
https://mesur.io/

Grab a meeting!
https://calendar.app.google/aNUcr41gvTAiMUG49


On Mon, Jul 22, 2024 at 5:44 PM Richard Barnes <[e-mail]> 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.
>
> --Richard
>
> On Mon, Jul 22, 2024 at 7:25 PM Watson Ladd <[e-mail]> wrote:
>
>>
>>
>> On Mon, Jul 22, 2024, 3:30 PM John Bradley <[e-mail]> wrote:
>>
>>> I agree that single-use proof keys and batch issuance are a must.
>>>
>>> Issuer verifier collusion is admittedly a problem.   To address that we
>>> do need different cryptographic methods.
>>>
>>> MDOC also has the same issue.
>>>
>>> We should document the risk, but short of stopping EUID and mobile
>>> driver's license deployment, we have limited options.
>>>
>>
>> The problem only appears when the drivers license or EUID is used in a
>> way that makes the user think their data is private. You don't have to
>> support UX that lies to the user.
>>
>>
>>> Hopefully, we can make quick progress on JWP.
>>>
>>> John B.
>>>
>>> On Mon, Jul 22, 2024 at 2:14 PM Watson Ladd <[e-mail]>
>>> wrote:
>>>
>>>> Dear Oauth,
>>>>
>>>> I'm disappointed to see SD-JWT work continue with inadequate privacy
>>>> considerations. The fact is an Issuer can link any showings to
>>>> issuance of the credential. This is not foregrounded sufficiently in
>>>> privacy considerations, nor do we discuss how to ensure users are
>>>> aware. We really need to use more RFC 2119 language and highlight
>>>> these issues. Section 11.1 about local storage which has never been an
>>>> IETF concern before is far more prescriptive than 11.4, and that's not
>>>> a good thing. To be clear, the threat model must include an issuer
>>>> that is a government issuing credentials that if used to verify age on
>>>> certain websites or via a digital wallet on site, and learned about by
>>>> the issuer who may have access to data from the site, will result in
>>>> imprisonment or execution. This is not a hypothetical scenario.
>>>>
>>>> Users and UX designers will have intuitions that do not match the
>>>> reality and that result in bad decisions being made. That's on us. A
>>>> driver's license doesn't leave a trace of where you showed it, but the
>>>> SD-JWT does.
>>>>
>>>> At a minimum I think we mandate batch issuance and one time usage
>>>> using RFC 2119 language. We need to say in clear, unambiguous English
>>>> that this mechanism enables an issuer to connect every presentation of
>>>> a credential to the issuance.
>>>>
>>>> Sincerely,
>>>> Watson Ladd
>>>>
>>>> --
>>>> Astra mortemque praestare gradatim
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>