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
