Dan Libby asks about this in private e-mail. I got his permission to post some of the exchange because I’m sure others are pondering the same questions. I edited it a little bit.

Dan writes:

In reference to: http://lid.netmesh.org/wiki/LID_2.0_VCard_Profile:

1) Am I missing something? It seems to me that any profile exchange mechanism that people will actually trust must allow for privacy of the users data.

Absolutely. Anything from “you get everything” to “you get nothing” to “you get only fake data”. (I’m not necessarily condoning the latter, but a system must support it, otherwise so many people simply won’t adopt it for many kinds of interactions.)

This implies:

a) the profile data is not at a publically accessible URL unless the user so authorizes. If this is not the case, what is to stop me from writing a spider to aggregate profile info ( in handy xml format even ) and sell it to spammers?

Because the URL will not return any data unless the owner of the URL allows the particular client to have access to it.

Sort of like HTTP Basic Auth — you can have the protected URL all you want, because you can’t see what’s behind unless you provide the correct credential.

b) the profile exchange mechanism permits the consumer website to access profile data only after the profile owner has authorized the consumer to do so.

c) b, in turn implies some sort of authorization token that the identity server provides the consumer.

and possibly:

d) the user can control exactly which data the consumer can access/view.

I had assumed that LID has mechanisms for the above, but the above-referenced page doesn’t metnion them. So, am I not looking in the right place, or…? It occurs to me that possibly this is defined somehow in another LID profile. If so, perhaps you can acknowledge/reference that and/or provide examples?

The LID profiles are designed to be orthogonal. You can use LID_2.0_VCard_Profile with or without making the URL a RelyingParty aka Identity Consumer. If it isn’t a Relying Party, it does not rely on identity assertions (tautology) and thus it cannot implement a big switch/case statement on who the client is, and so it must return the same information to everyone.

But if it is also a Relying Party, then I knows who the client is — and can dispatch appropriately, say, “give cell phone number to Joe only”.

This kind of orthogonality is generally a LID design principle, which now implicitly is also used for YADIS. Other profiles use that as well.

Add-on at 11am:

do you have any suggestions for integrating LID style authenticated profile exchange on top of openid? Is that a realistic possibility?

It absolutely should be. While at NetMesh, we haven’t done this yet in code, the basic idea is the same: browser authenticates with identity consumer (aka relying party) and then performs a query for certain profile information. The identity consumer, which would also be the target of the query per current YADIS spec, can look at the OpenID session cookie (or whatever it does to keep track of browser sessions) and filter its response appropriately. Another example of orthogonality in action…