Sharing Profile Information

[Martin Atkins]

David Recordon wrote:
> I'd tend to agree with the general feeling that an OpenID messaging client is outside the scope of the project.  However, it seems like adding the ability to share user definable profile information is not.  Thus solving the messaging problem of allowing users to share their email address (public, server they auth'd to only, etc).  Same would be applicable with a range of information from screennames to vCards.  This seems like it was already in the works by the message you get when verifying your identity about only sharing information you have decided to share.  I know this is something we've talked about a bit with LiveJournal in terms of allowing comment reply notification as well as for abuse issues such as spamming.
> 
> Thoughts?
> 

I agree that there needs to be provision for this, but we must be 
careful to keep a strict layered approach. The bottom layer is what we 
have now. Everything else should work above this, with no changes to 
what we already have. In particular, this means that the profile 
exchange should be a separate request, with its own separate 
confirmation step.

I'm getting a feeling in the back of my head that this "sharing profile 
information" can be reduced to a much more generic problem. I'm not 
quite sure what that is yet, whether it be just a generic property 
fetching mechanism (with namespaces for extensibility) or whether this 
can even be part of the permissions/RPC-like system we've been 
mentioning in passing several times. For example, a separate site calls 
an LJ-exposed function to post an entry for a given ID; user is prompted 
by LJ for permission, and if acknowledged the request goes through and 
the entry is posted. Is this the same as when separate site calls an 
exposed function to retrieve a piece of profile information, with the 
user asked for permission and the value returned?

It seems compatible to me, at least in a technical sense. How it's 
presented to the user is a different matter, of course. Would a user 
understand the implications if given a prompt like this?:

The site http://www.someone.com/ would like to do the following:
* Retrieve your email address
* Retrieve your display name
* Retrieve your birthday
* Post an entry in your journal

Do you give permission for the site to do all of these things?
     [Yes] [No]

(Note: I imagine the entry posting thing would in practice be 
implemented by the "RPC" function returning a token and other necessary 
information so that the requesting site can separately post an entry via 
a call to, say, the AtomAPI endpoint. Sending the entry text itself 
through the redirect-o-rama will cause some huge URLs.)

I think there's value in putting as much as possible together into a 
single, generic mechanism. Atop that namespaces (which can have 
inter-dependencies) will allow a variety of applications. Applications 
can request several operations at once as in my example above, but the 
request will be rejected if any of them aren't supported, perhaps.

Something to think about, anyway.