[OAUTH-WG] Re: We cannot trust Issuers

[Wayne Chang <[e-mail]>]

Yep, TEEs definitely have limitations that should be managed via
defense-in-depth to prevent things like side channel attacks.

It’s also true that such identity systems based on transmission of raw
digital signatures have been deployed in production today and continue to
gain momentum.

It’s important that we balance the various approaches to privacy, as not to
let perfect be the enemy of the good, while also paving a path to the ideal.

Best,
- Wayne

On Mon, Jul 22, 2024 at 20:33 Watson Ladd <[e-mail]> wrote:

> And the draft doesn't have a sufficiently strong statement saying this
> tech (which has significant limitations: every TEE has fallen due to side
> channels) is needed for relevant application scenarios.
>
> I'm not saying this work shouldn't continue: I'm saying that we need to
> ensure we get the privacy and security considerations right, and make clear
> the limitations and that users shouldn't be mislead about the degree of
> anonymity they have. The applications being envisioned are dangerous.
>
> Sincerely,
> Watson Ladd
>
> On Mon, Jul 22, 2024, 6:51 PM Wayne Chang <[e-mail]> wrote:
>
>> Hi Watson,
>>
>> Here’s an approach based on TEEs that can in theory create unlinkability
>> for things like mdocs and SD-JWTs while also conforming to FIPS 140-2/-3.
>> No new crypto, and PQC-friendly.
>>
>>
>> https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/
>>
>> Best,
>> - Wayne
>>
>> On Mon, Jul 22, 2024 at 16:26 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]
>>>
>>