[OAUTH-WG] Re: We cannot trust Issuers

[Nat Sakimura <[e-mail]>]

IMHO, it is just a matter of setting the reader's expectations right
through adequate privacy considerations. When it comes to collusion
attacks, we can think not only of issuer-verifier but other varieties as
well. We should perhaps list those scenarios. In ISO/IEC 27551 that only
deals with the model without holder, it still lists 8 varieties of
unlinkability. We will have many more in the issuer-holder-verifier model.
We should  be aware that there is an operator behind the holder, which can
turn hostile.

Best,

Nat Sakimura

2024年7月23日(火) 13:35 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]
>>>>
>>> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>