In the absence of any other controls, relying parties for identity info would like to be handed as much user data as they can get. It can’t hurt to have a little extra, right? But as we pointed out in the UMA webinar a few weeks ago, when web apps think they’ve gotten something valuable out of us, sometimes they’re just mistaken. When a site wants too much info and makes us give it to them in a self-asserted fashion (oh, those asterisked fields!), we just…lie. In fact, you can tell the site doesn’t do anything really important with that info if you can lie and get away with it.
Case in point: The crap that fills the fields of 77% of domain name registrations. (The Register’s headline: Whois in charge? ICANN’t tell. Heh.)
This is where “attribute assurance” could come in, involving a federated identity system that arranges for the data to be supplied by trusted issuers in some fashion. Attribute assurance is akin to identity assurance (as discussed previously here), except that it’s about the quality of specific types of information and their binding to the individual in question. The world hasn’t yet come up with a generic way of handling such assurance, though it’s been a topic of serious discussion. The Tao of Attributes workshop was a great start.
In the domain name registration case, one of the big reasons why people don’t like to supply their real information is that it’s published far and wide — anyone can learn what your address is if you provide your real one. Hence the lying, at least in quite a lot of the cases. This is a real-world situation where needs for level of assurance (LOA) are in a tug-o’-war with needs for level of protection (LOP).
What’s LOP? In short, it’s the reciprocal of LOA. Whereas relying parties want to ensure that the data they’re getting is good when they get it, data subjects and their identity providers want to ensure that the data will be protected and treated with respect when it gets there.
(You can read more about LOP, and some of the elements that need to be lined up to solve it in an Internet-scale way, in The 
Open 
Identity
 Trust
 Framework
 (OITF)
 Model, a white paper I was honored to co-author along with Tony Nadalin, Drummond Reed, Don Thibeau, and our illustrious managing editor Mary Rundle. The proposed model suggests some ways to organize the Pushmi-pullyu nature of federated identity partnerships to raise the quality, and possibly tamp down the quantity, of identity attributes floating around.)
Eve,
With the inaccurate data and people not wanting to disclose it, I think we do unfortunately have to look at motive.
For those whose motive is what I’d call typical “privacy protection” then there are legitimate services that provide this capability today. Unfortunately evidence has shown that the vast majority of private-proxy registrations are actually by those not with privacy motives, but illegal motives.
The real trick here is unfortunately going to be how to structure the system so that the system is general privacy preserving to the extent it should be, but that it still allows for unmasking of those behaving illegally.
I don’t yet know where that balance point is unfortunately.
Agreed that bad guys are using this hole in the system to do bad things. The article does give the impression, however, that perhaps as many as twice as many registrants have reasonable justification to be nervous about handing over good-quality data, vs. obvious bad guys who have nefarious reasons to lie.
Clearly the registrars could be deploying earlier and more sophisticated checks on the data (or accepting third-party sources for such data that they trust, as discussed above). Depending on how strongly the legitimate registrants feel about the inadequate protection of the data by ICANN, they could still foil some of these methods. It certainly seems that the situation is currently so dire that ICANN probably isn’t in a mood to demand that registrars deploy methods with really high attribute assurance, because it’s costly to do so. So the legitimate resisters will continue to get mixed in with the fraudsters, which is a shame.
My guess is that treating the data with more respect, and publicizing that they’re doing so, would probably cause more good guys to give real data. What are the real use cases for random people looking up domain owners? Could that be throttled a lot more?
Can Level of Protection leverage the proposed Oracle IGF (CARML and AAPML)?
I think possibly it could. To the extent that requirements can be expressed in unambiguous language, whether or not it ends up being machine-read in practice, is definitely a step up in any case.