> > 1) Disclosure of an identifier allows a service attack using that > identifier.
Sure, would you be able to say more about this though, I'm not sure I'm fully grasping the consequence here. 2) Linking separate uses of an identifier allows a profile to be > constructed of the individual that can be used against the interest of the > individual. But isn't the user aware that the AS is sharing with the client the same identifier and therefore will be tracked. Isn't it their prerogative if they want to be and then decide whether to do that or not? There are lots of cases I want the different clients to know how to track me and other cases where I don't want that. It would just seem to be of poor design that this decision is not provided as a fundamental property of the AS being used rather than an aspect of OAuth, OIDC, or anything else, right? Two parties that collude may always be able to figure out if an entity is the same identity in those clients, it sounds like we are saying there is something that could have been done to actively prevent that. But I'm not following what that is. I also find the US banking system of routing number + account Id deplorable, but I don't see what that has to do with our discussion. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Mon, Mar 1, 2021 at 9:13 PM Phillip Hallam-Baker <[email protected]> wrote: > Lets take a step back. There are two separate sets of concerns related to > 'privacy' > > 1) Disclosure of an identifier allows a service attack using that > identifier. > > 2) Linking separate uses of an identifier allows a profile to be > constructed of the individual that can be used against the interest of the > individual. > > The reason I insist on this distinction is that privacy issues of the > first type are a consequence of crappy protocol design. There is absolutely > no reason why giving someone my bank details so they can send a payment TO > me should give them the ability to withdraw money from my account. But it > does and the banks will smugly gaslight that it just isn't possible to fix > this elementary flaw in their information architectures. And you can guess > where it came from if you hear the question being asked in the relevant > Senate hearing of the form, 'Mr CEO, you say that it would be impossible to > make this change, what size of penalty per loss are we going to have to > impose on your bank to make it cheaper for you to fix it than to claim it > can't be done?' > > It should be possible for Madonna or Lewis Hamilton to put their personal > contact info on their Web sites without ending up being spammed to > oblivion. It is just a question of access control. > > > The second is a really difficult problem but authentication is only one > small part of it. I can turn out a public key authentication scheme that > allows Alice to surf the web at Bob and Carol's site without them being > able to tell its the same person from the identifier easily enough. But all > bets are off if Bob and Alice collude. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
