OpenID & LID in a passel-world

[S. Sriram]

> Having played around with OpenID, I realize it has serious limitations.
...
> actually catapult it out of obscurity.  The big limitation is the lack
> of verified profile information.  While that can be solved at higher

Distributed interception & Distributed aggregation

The fact is that to exchange profile data, there needs to
be user involvement and multiple third party counter-signing.

Passel-agent via a browser plug-in solves the user involvement
need and a standardized xml data exchange protocol allows for
multiple third party counter signers of data elements.

In the 'OpenId as identity authentication with a PassOpen server
for passel based profile exchnage' model, the PassOpen server
acts as the aggregator of my data.

Is there a better choice between me aggregating my data in my
browser or me appointing an agent to aggregate my data ?

A distributed aggregation service whereby I can choose a third
party agent for different profile data elements and therby
ensure that no one party is privy to all my secrets. I would
appropriately make notification within the head element of my
identity url.

Well, isn't that exactly what passel-signers are, distributed
third party agents for different profile elements. All signers
would need to do is tack on some agent functionality such as
'do you want to send this info' and bob would go through
multiple such user intercepts for each data element that he wanted
send to target. And for self-asserted data elements where my browser
played the passel-signer role the passel-target would play agent.

This can be accomplished by clever client side programming such as
iframe-ing the list of  signers in one screen (for third party &
self-asserted
data elements) or similar ui tricks.

To summarise:

Exchanging profile data requires
 - user intervention
 - third party counter signing

three ways to accomplish this are
1. The passel way (My browser aggregates and performs user intervention)
    (Issues around adoption i.e. browser plug-ins etc.)
2. The PassOpen way: Moving the passel-agent from browser to service and
   using OpenID identity url to discover it.
   (Issues around data ownership, my agent is now privy to all my data)
3. The OpenPassPass way: Tacking on user intervention functionality onto
   passel-signers and aggregrating the required data set for user
intervention
   in an iframe-d ui  that the passel-target (website) throws up on
discovery
   via OpenID's  identity url.
   (The cleanest way, places a slightly heavier programming burden on
    signers/servers & targets/consumers but could be solved with some
    clever programming)

It maybe useful here to consider building a passel-variant that does 3 for
OpenID's profile data gathering piece and turning
OpenId into the lightest entry into the identity world
which incrementally leads to greater degrees of identity-profile
data sharing, all by bob adding lines to his identity_url.

Thanks
S. Sriram