[OAUTH-WG] Re: We cannot trust Issuers

[Richard Barnes <[e-mail]>]

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]
>