OpenID & LID in a passel-world

[Xageroth Sekarius]

There will never be (nor should there ever be) one identity system to
rule them all.
OpenID and LID will remain relevant so long as they remain the best at
their respective approaches to identity. Same goes for Passel.

Just my humble opinion. I think dreams of an identity system
dominating the world should have died with Passport.

On 7/23/05, S. Sriram <ssriram at gmail.com> wrote:
> Hi,
> 
> The significant limitation with passel is the need for
> end user browser support, this however is counterweighed
> by the opportunity of having any element of profile data
> (such as email id) be authenticated (not just passed),
> and each element having its own signer.
> 
> (Passel: an open-protocol/technology similar to OpenID.
> more at http://www.passel.org/whitepaper.html )
> 
> So, if passel's limitation i.e. browser support goes away
> because at some later date all browsers support it, than how
> would openid live/be relevant in this passel-world ? and
> what about LID ?
> 
> It seems to me that the actual identity url would become a profile
> data element effectively authenticating one's public name in
> guestbook/comment and other situations where what is needed
> is a name.
> 
> So, in a passel world
> 
> Target(website) asks agent(browser) the following q's
> 
> What is your public name ?
>  an OpenID url or LID url can authenticate this
>  In OpenId's case: The passel-signer would need to be an openid consumer
>  that talks to an openid server and sends back data in the format
>  that passel-target needs.
>  In LID's case: The passel-target would need to be LID-aware to be able to
>  authenticate a LID url. (not likely)
> 
> What is your email id, tel, dob etc..?
>  Pure passel conversations.
> 
> So, in a REST-ful non-SOAP/WS-* world, what seems to be shaping up
> is that (given browser plug-in support) passel 'could' become the
> dominant profile exchange protocol/technology with OpenID providing
> the url/public name authentication service.
> 
> Since LID url's would have the added dependency of needing to be
> supported by passel-targets this may not be universally accepted.
> (as opposed to OpenId url's since they could point to an openid
> consumer that is passel-ready)
> 
> Which reduces to
> 
> End-User:
>    Get an OpenID url, it will stay relevant
> Consumer/Website:
>    Build openid consumer functionality today, expect to be a passel target
> tomorrow
> PassOpen servers (Passel Signer + OpenId consumers: )
>   A new breed of OpenId consumers who perform consumer services to
> passel-agents and signer services  to passel-targets.
> 
> I'd be interested in being pointed to any links that outline some of the
> issues/differences.
> 
> Thanks
> S. Sriram
> 
> 
> 


-- 
Xageroth Sekarius
[ http://digitalmyth.net/ ]:[ http://xageroth.blogspot.com/ ]