[OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.

[Wayne Chang <[e-mail]>]

Hah, nationalization of telcos sounds very spicy and dangerous! I think a
private sector entity (corp, non-profit, PBC, trust company, etc.) that is
certified by an org like Kantara for identity provisioning with the
upcoming NIST SP 800-63-4 would be interesting, and it could support a
variety of cryptographic mechanisms for issuing anonymous tokens to enhance
privacy, but also CMVP-friendly ones. Let's Encrypt is a good case study
from the land of CAs, and you could imagine retooling ACME with oauth2 to
support delegated PIV. However, we may be veering outside of the scope of
the list with this topic.

Best,
Wayne Chang
Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
<https://www.linkedin.com/in/waynebuilds/>


On Wed, Dec 25, 2024 at 02:34 Tom Jones <[e-mail]>
wrote:

> There is always the potential to come up with a cred that will be accepted
> as enabling access to some resource.
> There are some proof mechanisms that state that the bearer has a cred that
> enables access.
> What we have not achieved is a mechanism that ties the cred to the holder
> without an ID number binding to the holder.
> That would be a good thing - but the only way I know involves trusting the
> telco - which we all know is a dead end.
> What other mechanism can bind the holder to the device w/o the telco (or
> do we just nationalize the telcos again.)
>
> Peace ..tom jones
>
>
> On Tue, Dec 24, 2024 at 10:29 AM Wayne Chang <[e-mail]> wrote:
>
>> No, I don’t mean an ID number. More so attributes of an entity attested
>> by a non-governmental entity, and it could use privacy enhancing
>> cryptography in this steelman.
>>
>> Best,
>> Wayne Chang
>> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
>> <https://www.linkedin.com/in/waynebuilds/>
>>
>>
>> On Wed, Dec 25, 2024 at 02:17 Tom Jones <[e-mail]>
>> wrote:
>>
>>> if by ID you mean ID number - then it is a tracking number.
>>> Isn't it super obvious - why are we pretending to be privacy enabling?
>>>
>>> Peace ..tom jones
>>>
>>>
>>> On Tue, Dec 24, 2024 at 10:15 AM Wayne Chang <[e-mail]> wrote:
>>>
>>>> Tom, how do you feel about private sector issued ID?
>>>>
>>>> Best,
>>>> Wayne Chang
>>>> Founder & CEO | SpruceID <https://spruceid.com/> | LinkedIn
>>>> <https://www.linkedin.com/in/waynebuilds/>
>>>>
>>>>
>>>> On Wed, Dec 25, 2024 at 02:04 Tom Jones <[e-mail]>
>>>> wrote:
>>>>
>>>>> While Waton's statement is correct - it does not address the core
>>>>> problem with any credential that comes with an ID.
>>>>>
>>>>> All reusable IDs enable tracking.  Full Stop.
>>>>> All government issued ID enable tracking. Just like social insurance
>>>>> number or any other cred.
>>>>> So - if you want privacy - don't release the ID number.
>>>>>
>>>>> Peace ..tom jones
>>>>>
>>>>>
>>>>> On Tue, Dec 24, 2024 at 6:34 AM Watson Ladd <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> I see that people are uncomfortable with making any mandates, and so
>>>>>> I've tried to be purely descriptive in this proposal. I leave it to the WG
>>>>>> to decide where to put it, but I see it as a wholesale replacement for some
>>>>>> sections to emphasize clarity.
>>>>>>
>>>>>>  "SD-JWT conceals only the values that aren't revealed. It does not
>>>>>> meet standard security notations for anonymous credentials. In particular
>>>>>> Verifiers and Issuers can know when they have seen the same credential no
>>>>>> matter what fields have been opened, even none of them. This behavior may
>>>>>> not accord with what users naively expect or are lead to expect from UX
>>>>>> interactions and lead to them make choices they would not otherwise make.
>>>>>> Workarounds such as issuing multiple credentials at once and using them
>>>>>> only one time can help for keeping Verifiers from linking different
>>>>>> showing, but cannot work for Issuers. This issue applies to all selective
>>>>>> disclosure based approaches, including mdoc. "
>>>>>>
>>>>>> Sincerely,
>>>>>> Watson
>>>>>> _______________________________________________
>>>>>> 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]
>>>>
>>> _______________________________________________
>> OAuth mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>