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

[Pierce Gorman <[e-mail]>]

What mechanism(s) are you referring to that “involves trusting the telco”?

Telecoms providers vary widely in their abilities (and regulatory regimes), and the telecoms technology continues to evolve.

Voice over IP (VoIP) wasn’t really a thing 30 years ago but I will assert the majority of network-to-network interconnection is now dominated by VoIP.  And, the dominant VoIP protocol (Session Initiation Protocol aka SIP) was originally designed to operate peer-to-peer, and it isn’t hard to imagine a day when peer-to-peer will be the dominant operation instead of telecoms network to telecoms network.

Whatever mechanism you think would be the “good thing” needs to be able to exist independently of existing telecoms infrastructure.

Pierce



CONFIDENTIAL
From: Tom Jones <[e-mail]>
Sent: Tuesday, December 24, 2024 12:34 PM
To: Wayne Chang <[e-mail]>
Cc: [e-mail]; John Wunderlich <[e-mail]>; IETF oauth WG <[e-mail]>
Subject: [OAUTH-WG] Re: Alternative text for sd-jwt privacy considerations.


EXTERNAL EMAIL
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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
OAuth mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>