Third, it suggests that whatever metadata the user doesn't provide
herself, a site author may attempt to harvest elsewhere.
Which is something we need to establish best practices around, to
discourage just that: the *attempt* to harvest correlating
(meta)data elsewhere. Site authors who mix up authentication data
and accidentally commit identity theft on the user's behalf will
not be admired.
Care to unpack that? I always felt that it's foolish not to use
public data to inform interaction with the user.
Collisions in namespaces that are not as unique as they were assumed
to be (e.g., first/last names) or a lack of trustworthiness in public
sources, either of these can lead to correlatable metadata that,
frankly, really doesn't belong together.
If the RP is so foolish as to use publicly available E-mail addresses
(gathered through whatever harvesting process) as backups when the
account holder's primary address bounces, or even to passively allow
authentication from alternate accounts that are "merged" (feature of
convenience - user can "rapidly switch" to their other accounts
without having to logout/login!), they will have just compromised the
user's account (not with other RP's, unless feeding those RP's
"reliable" data!).
If the RP simply republishes that metadata, other agents will take
account of it, possibly suspending their own critical examination
algorithms *because* that data came from a "trustworthy" source.
Suddenly, the intrawebz are broadcasting that Benjamin Laurie, an
innocent baker in a small Illinois town, has a profile at that RP
asking everyone to also check out his contributions to the security
of the internet: the RP has inadvertently framed him for plagiarism
at best, (attempted) identity theft at worst.
It should also be obvious that, if someone has set up a very
convincing set of internet identities all pointing at Profile A, and
Profile A doesn't point back at any of them, there may well be more
at stake here than just a user trying to be anonymous: those other
profiles could simply be a setup, an attempt to become associated
with that user and thus to steal their identity. Associations "in the
wild" are even more complicated, in how they all point at one
another, but it's still very simple to keep track of if you just
stick with *the known user's* assertions and treat any identity
claimed thereby as golden.
-Shade
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs
