boy - this came in out-of-context. I hope that wasn't caused by me posting to the wrong site. I was responding to someone else about trusting the telco. We can see cases where the phone number maps to something real. Trusting the telcos to map the number to something real is basically unacceptable to them. Several countries (Estonia, India) try to register SIM cards and use the SIM as a link to something real. That does make sense from a security standpoint. But that hasn't worked well in practice and now physical sims are not even available in some countries (most phone in US)
So - what trust infrastructure "needs to exist". That's a real question that deserves a real answer. Not clear who has the smarts and authority to do that. Peace ..tom jones On Thu, Dec 26, 2024 at 10:08 AM Pierce Gorman <pierce.gor...@numeracle.com> wrote: > 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> 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> > 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> 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> > 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> 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 > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
