headers
S. Sriram | 24 Jul 00:20
Picon

OpenID & LID in a passel-world

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
Permalink | Reply |
headers
Xageroth Sekarius | 24 Jul 05:32
Picon

Re: OpenID & LID in a passel-world

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/ ]
Permalink | Reply |
headers
jay | 25 Jul 16:17
Picon

Re: OpenID & LID in a passel-world

*



Xageroth Sekarius wrote:

>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.
>


I'm not so sure about that.  It's great that there is a data transport 
protocol that we can all agree on to move web pages around the 
internet.  Same goes for mail (this isn't an argument for how good these 
protocols are :) and tcp/ip itself (itselves?).

I don't want to have several different identities so that I can be sure 
I can identify myself on every site, I want one that works everywhere, 
just like my web browser works everywhere.

Following your argument, it's perfectly okay that microsoft uses their 
own sort of html, css and javascript, instead of complying with web 
standards.

We need to eventually agree on one and go with it.

My two cents,
Jay K
Permalink | Reply |
headers
Rob Lanphier | 24 Jul 08:51
Picon
Gravatar

Re: OpenID & LID in a passel-world

*



On Sat, 2005-07-23 at 23:32 -0400, Xageroth Sekarius wrote:
> 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.


<by that line of logic>
There will never be (nor should there ever be) one information delivery
protocol to rule them all.

gopher and wais will remain relevant so long as they remain the best at
their respective approaches to information delivery.  Same goes for
HTTP.
</by that line of logic>

Sometimes, a technology "wins" by most metrics.  Just because it hasn't
happened yet for identity systems, doesn't mean that it won't.  Some
systems, like Passport, were doomed to fail for obvious reasons we don't
need to rehash here.  However, just because there have been failures in
the past, doesn't mean someone won't stumble on a killer combination
that solves the problem well enough for a huge class of problems to
relegate the other techniques to obscurity.

Rob
Permalink | Reply |
headers
S. Sriram | 24 Jul 18:18
Picon

Re: OpenID & LID in a passel-world

*



> Sometimes, a technology "wins" by most metrics.  Just because it hasn't


Live journal had 7 million identity urls. OpenID turned these into
authenticable profile data elements. Blog/Comments being the use case 
and this now creates an ever expanding cycle of adoption.

Large Email service providers have multi-million email accounts. 
Which identity system can turn them into authenticable profile 
data elements ?

Passel is clearly well positioned to do this, the only
challenge being providing a service that motivates the user to 
'download the plug-in'.

OpenID by design is inherently incapable of authenticating other
profile elemnts, it can be modified to 'pass' other data elements
such as foaf data but not authenticate them. Even if one builds
a special purpose consumer/server that provides an email
verification service, you still need a standard handshake
between consumers and servers and also with the end-user i.e.
does he want to share this data element or not.

Passel incorporates all of that for email AND other data elements.

So then the question becomes would passel live in an OpenID world 
or vice versa. It seeems to me that OpenID will have to live in
a passel world.

LID since it does not have a large seed base and therefore no
increasing cycle of adoption would contribute its ideas to the
new identity framework rather than adoption. So, if one were to
build a non-authenticated light weight profile passing mechanism
that tacks onto OpenID, one might consider having pointers to
FOAF, vcard data etc. within the identity_url head that specialized
consumers/servers process.

Thanks
S. Sriram
Permalink | Reply |
headers
Rob Lanphier | 24 Jul 20:01
Picon
Gravatar

Re: OpenID & LID in a passel-world

*



On Sun, 2005-07-24 at 09:18 -0700, S. Sriram wrote:
> Large Email service providers have multi-million email accounts. 
> Which identity system can turn them into authenticable profile 
> data elements ?
> 
> Passel is clearly well positioned to do this, the only
> challenge being providing a service that motivates the user to 
> 'download the plug-in'.


That's a huge assumption.  Getting end users to install client software
is not a step that you can skip over.  In fact, it's quite likely the
Achilles heel of the whole project.  The fact that they ask you to use
CVS to grab a Mono reference implementation means that they are in no
danger of taking over the world anytime soon.  

/If/ they can convince the Mozilla folks to include an implementation in
Firefox /by default/, they /may/ have a chance.  That's not the only
path to viability, but that's the only one I could envision actually
happening.  I doubt they would, though, because if I were in Mozilla's
shoes, I'd look instead to some small extension to their existing saved
form and saved password functionality, rather than the full parallel set
of functionality that this would seem to require.

Having played around with OpenID, I realize it has serious limitations.
However, it solves one problem well enough (and simply enough), and is
the only one I've seen with a viable bootstrapping mechanism so far to
actually catapult it out of obscurity.  The big limitation is the lack
of verified profile information.  While that can be solved at higher
layers, there probably needs to be a de facto standard for actually
doing it, which would involve a really compelling implementation
including the extended functionality. (e.g. .gif became the de facto
standard for images in HTML when it was included in Mosaic).

Rob
Permalink | Reply |
headers
S. Sriram | 24 Jul 21:22
Picon

Re: OpenID & LID in a passel-world

> 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
Permalink | Reply |
headers
S. Sriram | 24 Jul 20:12
Picon

Re: OpenID & LID in a passel-world

*



> That's a huge assumption.  Getting end users to install client software
> is not a step that you can skip over.  In fact, it's quite likely the
> Achilles heel of the whole project.  The fact that they ask you to use


Passel agent as service that hangs of identity url

bob goes to ecommerce site (target)
provides OpenID
target reads OpenID url for controlling OpenID server
and controlling PassOpen (PO) service
target authenticates OpenID against OpenID server
target sends PO it's passel-target request xml
PO performs the role of passel-agent for the OpenID
   - makes user input request as needed
   - sends data to target

What this does is it removes the need for me to be my
own passel-agent but rather use an agent-service. My OpenID
being my gateway to it. This removes browser related
dependencies.

A PassOpen service could be developed by any third party
Browsers don't need plugins
Passel-Agents don't discover target needs, but targets explicitly
state them on OpenId authentication.
Web sites would need to add the passel functionality behind
their OpenID curtain.

Thanks
S. Sriram
Permalink | Reply |
headers
Xageroth Sekarius | 24 Jul 09:27
Picon

Re: OpenID & LID in a passel-world

On 7/24/05, Rob Lanphier <robla <at> robla.net> wrote:
> On Sat, 2005-07-23 at 23:32 -0400, Xageroth Sekarius wrote:
> > 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.
> 
> <by that line of logic>
> There will never be (nor should there ever be) one information delivery
> protocol to rule them all.
> 
> gopher and wais will remain relevant so long as they remain the best at
> their respective approaches to information delivery.  Same goes for
> HTTP.
> </by that line of logic>

I agree with that line of logic (despite your implied cynicism?). FTP
and SMTP and a few others (
http://en.wikipedia.org/wiki/Application_layer ) you know of would
agree as well.

> 
> Sometimes, a technology "wins" by most metrics.  Just because it hasn't
> happened yet for identity systems, doesn't mean that it won't.  Some
> systems, like Passport, were doomed to fail for obvious reasons we don't
> need to rehash here.  However, just because there have been failures in
> the past, doesn't mean someone won't stumble on a killer combination
> that solves the problem well enough for a huge class of problems to
> relegate the other techniques to obscurity.
> 
> Rob
> 
> 
> 

The reasons for Passports failure are only obvious by hindsight. The
same will be said for the pro's and con's rap sheet of the next batch
of identity systems. I'll concede it's possible someone could stumble
upon a "killer combination", sure, but so long as that solution is
easily made interoperable with different solution perspectives nobody
will be locked into a failing system when hindsight begins to kick in.

Browser plug-ins (like URL-based identity) are only attractive to a
particular crowd. Just playing devils advocate because <by my line of
logic>more options are better</by my line of logic>

--

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

Gmane