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 <thomasclinganjo...@gmail.com>
Sent: Tuesday, December 24, 2024 12:34 PM
To: Wayne Chang <wa...@spruceid.com>
Cc: pe...@acm.org; John Wunderlich <j...@wunderlich.ca>; IETF oauth WG 
<oauth@ietf.org>
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 
<wa...@spruceid.com<mailto:wa...@spruceid.com>> 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 
<thomasclinganjo...@gmail.com<mailto:thomasclinganjo...@gmail.com>> 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 
<wa...@spruceid.com<mailto:wa...@spruceid.com>> 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 
<thomasclinganjo...@gmail.com<mailto:thomasclinganjo...@gmail.com>> 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 
<watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>> 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 -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org>
To unsubscribe send an email to 
oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to