OpenID Problems / Solutions

[Daniel Parker]

I've been reading discussions about the concerns of OpenID since it
came out, and I've had some of the same concerns. I want to list these
main concerns (that I've seen) and then present a possible way they
could all come together. I haven't been in the brunt of the workforce
of OpenID, so I might be dead wrong, but I might have a valid argument
and I want to see all the opposing reasoning. Feel free to correct or
clarify any one point I have listed below.

1. The reason we came up with OpenID is so that we can have a single
method of signin for multiple sites, managed by one signin site that
you trust. Thus OpenID was created and has been implemented around the
web, with increasing momentum.

2. The foremost concern with OpenID is that multiple sites could make
connections together between data tied to your openid without your
consent. This has been solved by allowing users to choose an
identifier at their OpenID provider on a per-site basis.

3. Point #2 was, in my opinion, the wrong correction of the problem.
It was a step that was 45º off-target. The user should not have to
manage at the point of signin which sites he wants to trust to treat
his openid as it should. Every user should be automatically protected
with a unique openid identifier at each site he visits.

4. My suggested solution. An OpenID provider generates a unique id for
each site. (This should be recommended of every provider.) If any site
wants to connect with the user's data on another site, they should use
OAuth. If for any reason there is a need to equate user id's between
sites, it can be asked of the OpenID provider and naturally,
permission of the user would be required. Signin should ALWAYS be
simply by entering in the provider url, and not the user's identifier
(which they wouldn't really need after all).

I think this is all possible within current standards. If this is a
good idea, can it be pushed in recommendations and explanations of the
signin process?

[Aaron Cheung]

Re #4 solution, interesting to experiment with.. sounds like too much data of the
per-site unique-id's to keep track of for large idproviders..
unless the benefits really justify..
Regards, /ac.

[Daniel Parker]

Well, ONE solution that could be done is just a using a simple encryption of the consumer site with a secret only the provider knows... That way no data needs to be stored, as it can be derived on-the-fly. :)

~Daniel

--
"You have granted me life and steadfast love, and your care has preserved my spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"

[Aaron Cheung]

Managing a shared secret per user certainly sounds better than assigning a unique id for each site the user logins into ;-) (though along with all those secret keys management issues, but at least well demonstrated and proven by the Amazon cloud methodologies).. /ac.

[Daniel Parker]

It really only needs to be a secret key for the whole provider site, mixed with the user's username and the consumer site in question.

The idea is that you can still have a single-signin, but no individual site or group of sites would be able to match your data up by your openid identifier. Using a method like this would ensure that possibility, and users wouldn't really need to know each site's identifier for them. I think I'll implement this in my OpenID provider and see if I come up with any problems.

Does anybody else have any thoughts?

~Daniel

[Aaron Cheung]

Yes, my second thought to the same also.. will also try that out and see.. /ac.

[Brady Brim-DeForest]

"no individual site or group of sites would be able to match your data
up by your openid identifier"

That is, in my mind, extremely critical for protection of end-user privacy...

-Brady

--
Brady Brim-DeForest
www.brimdeforest.com

[Daniel Parker]

Imagine I have an openid at myopenid.com, but there is no "free-for-all" identifier like http://dcparker.myopenid.com/.

When I visit a site, I simply enter "myopenid.com" in their box (or click the link in the idselector) that says to them, "I trust myopenid.com to verify who I am and manage who can claim to be me."

When myopenid.com replies, they say:

NOT: that I *am* http://dcparker.myopenid.com/

RATHER: that I *can be persistently identified by* http://myopenid.com/users/dd00e5cbd95"

...meaning that every time myopenid.com authenticates me, it will return this same id, which can be matched up in their own database -- but NOT anyone else's databases.

The nice thing is that this is currently possible under the specifications -- but I believe it should be a *strong* recommendation.

The other big piece is that it kinda does away with the public's view of an OpenID Identifier... but it might actually be easier for the public to adopt OpenID without introducing this new "OpenID Identifier" concept. All they need to know is that they can signin through another site they already trust -- which is already rather popular.

~Daniel

[Brady Brim-DeForest]

Daniel,

I couldn't agree more – this should be a *strong* recommendation.

-Brady

[Jonathan Vanasco]

On May 19, 5:54 pm, "Brady Brim-DeForest" <brad...@gmail.com> wrote:
> I couldn't agree more – this should be a *strong* recommendation.

It shouldn't just be a strong recommendation, it should be required.

We started FindMeOn.com on that exact concept:that people would need
multiple identifers at each domain, one to represent each third-party
identity and serve as a conduit for the different personas , content,
and relations that can be shared.

We also use a public/private key pairing to digitally sign multiple
identifiers or accounts to one another -- this way they can be linked
together under privacy, and publicly verified by only those that are
trusted.

[Aaron Cheung]

Hmm, if required, issues, because of the intentionally fully distributed nature
of the protocol.. enough sites out there have low processing power (because
of shared hosting and other reasons) (and some sites are not operated in
very secure mode) to support full fledged identity mappings.

Being simple is a good path to success (eg., SMTP popularizing the original
internet and surviving with such minimalist capabilities for over 30 years..
extensions are good as we see today, but should not be required, for
mass adoption, in the Internet style..)

Secret keys also great, me also of the same thoughts, but should be like
extension of the extension of the protocol.. more secure, but more complicated
(than the beauty (and ugliness) of the smtp protocol, being compared to here)..
and if required, it's more for the games of the very big providers implementing
proprietary protocols, eg., amazon cloud's shared secret PLUS a valid timeframe
for signed requests... certainly more secure, but complicated -- even given the
3rd party libraries -- from my experience porting aws stuff from java to c++..

Regards,
/ac.

----- Original Message -----
From: "Jonathan Vanasco" <jona...@findmeon.com>
To: "DataPortability.General" <dataportabi...@googlegroups.com>
Sent: Tuesday, May 20, 2008 12:22 PM
Subject: [DataPortability-Public] Re: OpenID Problems / Solutions

[anders conbere]

On Mon, May 19, 2008 at 9:10 AM, Daniel Parker <dcpa...@gmail.com> wrote:
>
> I've been reading discussions about the concerns of OpenID since it
> came out, and I've had some of the same concerns. I want to list these
> main concerns (that I've seen) and then present a possible way they
> could all come together. I haven't been in the brunt of the workforce
> of OpenID, so I might be dead wrong, but I might have a valid argument
> and I want to see all the opposing reasoning. Feel free to correct or
> clarify any one point I have listed below.
>
> 1. The reason we came up with OpenID is so that we can have a single
> method of signin for multiple sites, managed by one signin site that
> you trust. Thus OpenID was created and has been implemented around the
> web, with increasing momentum.

Maybe I'm wrong but I see the reason for OpenID not being to create
single sign-on scenarios, but identity scenarios. The incredibly
useful pieces of openID to me, have more to do with having a unique
url identifier that can and should be linked to data which you
selectively distribute to third parties. Having an authentication
based system is more of a product of the identity requirement. It's
the proof of ownership, not the goal.

>
> 2. The foremost concern with OpenID is that multiple sites could make
> connections together between data tied to your openid without your
> consent. This has been solved by allowing users to choose an
> identifier at their OpenID provider on a per-site basis.

Is this the foremost concern? (this seems to be a natural progression
of data portability)

>
> 3. Point #2 was, in my opinion, the wrong correction of the problem.
> It was a step that was 45º off-target. The user should not have to
> manage at the point of signin which sites he wants to trust to treat
> his openid as it should. Every user should be automatically protected
> with a unique openid identifier at each site he visits.

How would you then publish those id's? would you use hopelessly obtuse
hash identifiers? Doesn't this destroy some of the transparency of
openID? And even if you did that, aren't those ID's really protected
only by obfuscation?

>
> 4. My suggested solution. An OpenID provider generates a unique id for
> each site. (This should be recommended of every provider.) If any site
> wants to connect with the user's data on another site, they should use
> OAuth. If for any reason there is a need to equate user id's between
> sites, it can be asked of the OpenID provider and naturally,
> permission of the user would be required. Signin should ALWAYS be
> simply by entering in the provider url, and not the user's identifier
> (which they wouldn't really need after all).

This sounds like a great idea if all openID provided was an
authentication end point (but you could model that with kerberos, or
ldap, or a simple database and some hashes). OpenID goes a step
further and suggests that you can take measures to assign value to a
unique identifier, and that if this identifier is canonical, there are
amazing tools that are exposed.

Removing the canonical nature of openID destroys many of it's
benefits, and turns it into simply another authentication solution.

~ Anders

[anders conbere]

On Mon, May 19, 2008 at 9:22 PM, Jonathan Vanasco <jona...@findmeon.com> wrote:
>
> On May 19, 5:54 pm, "Brady Brim-DeForest" <brad...@gmail.com> wrote:

>> I couldn't agree more - this should be a *strong* recommendation.

>
> It shouldn't just be a strong recommendation, it should be required.
>
> We started FindMeOn.com on that exact concept:that people would need
> multiple identifers at each domain, one to represent each third-party
> identity and serve as a conduit for the different personas , content,
> and relations that can be shared.

If the goal is to create internal contexts for the user there are much
better ways of accomplishing this than obscured hashes. (for instance
you could create a subpath of the openid that represents a resource,
and provide only auth / and data based on that url).

~ Anders

[Aaron Cheung]

Mightbe I missed something, but isn't this exactly about subpath auths anyway.. :-)

And, hmm, obfuscation (encrypted or simply hashed) does have valueable use cases..
eg., those facebook userids and blogspot profile ids etc, essentially stem from same idea
(of obfuscation) eg., http://www.blogger.com/profile/01234567890123456789...

I do agree that canonicalness is valuable.. though url's are not the most friendly
thing for the username string replacement.. a common grievance point... /ac.

----- Original Message -----
From: "anders conbere" <acon...@gmail.com>
To: <dataportabi...@googlegroups.com>
Sent: Tuesday, May 20, 2008 2:51 PM
Subject: [DataPortability-Public] Re: OpenID Problems / Solutions

[anders conbere]

On Tue, May 20, 2008 at 12:09 AM, Aaron Cheung <a...@mymesh.com> wrote:
>
> Mightbe I missed something, but isn't this exactly about subpath auths anyway.. :-)

The example given inline is definitely /not/ subpathed

>>When myopenid.com replies, they say:
>>NOT: that I *am* http://dcparker.myopenid.com/
>>RATHER: that I *can be persistently identified by* http://myopenid.com/users/dd00e5cbd95"

This example destroys the canonical-ness of openID, and in my opinion
makes it largely useless.

a more interesting usecase is something like having my root openid be

romeo.myopenid.com

with the possibility to append other resources

romeo.myopenid.com/the_window

you could create very interesting use cases there, while still
preserving the nature of the url identifier.

~ Anders

(maybe this already happens, in which case, "YAY openid picking
awesome solutions to problems I hadn't bothered to deal with" :-D)

[Aaron Cheung]

Ok I see what you mean.. but note that the original thread if I understand it correctly
was about enhancing privacy without loss of seamless user experience.. so the problem
here is the loss of canonicalness, but i'm more along the discussion of alternate extensions,
which might not be quite orthodoxically pursued... ;-) [but still should work, thus need
to expriment with].. cheers, /ac.

[Julian Bond]

Brady Brim-DeForest <bra...@gmail.com> Mon, 19 May 2008 13:44:06

>
>"no individual site or group of sites would be able to match your data
>up by your openid identifier"
>
>That is, in my mind, extremely critical for protection of end-user privacy...

Proviso. Unless you want to be matched up. And I'd suggest that wanting
to be matched up is the norm and avoiding it is the edge case.

--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
If Unobtainable Press Again

[anders conbere]

On Tue, May 20, 2008 at 12:44 AM, Julian Bond <julia...@voidstar.com> wrote:
>
> Brady Brim-DeForest <bra...@gmail.com> Mon, 19 May 2008 13:44:06
>>
>>"no individual site or group of sites would be able to match your data
>>up by your openid identifier"
>>
>>That is, in my mind, extremely critical for protection of end-user privacy...
>
> Proviso. Unless you want to be matched up. And I'd suggest that wanting
> to be matched up is the norm and avoiding it is the edge case.

Yep,

I think that's the foundation of a lot of what the social network
portability cases of data portability are built on. I think we can
honestly say that this generations gut feeling on privacy is radically
different than the previous generations. And I think this is well
founded. This isn't the say that privacy has really changed much.
People aren't opening up their rooms for inspection, or happy about
warrantless wiretapping. What's important here is the recognition of
the web as a very different privacy context than your home/school/work
etc.

Anyway, like I said before, I don't think making private ID's is the
foremost concern of openID, rather I think quite the opposite. The
foremost concern was providing public ID's that were linkable, and
then giving the user the ability to prove that an ID belonged to them.

~ Anders

[Daniel Parker]

I see some good conversation here -- two things have been brought up that I want to address:

1) Canonicalness of the OpenID.

    My understanding of OpenID is that the purpose of canonicalness is not so that sites can match up data, but so that users have one id to remember. My understanding of the *process* of OpenID is that it allows a consumer site to authenticate a user through a provider of his/her choosing, thus mutually trusting that site to persistently identify the user across sessions.

> "And I'd suggest that wanting to be matched up is the norm..."

    I disagree completely. To the average user, the branding of OpenID is "Single Signin!" To make an obvious note, it's called OpenIdentification, not CommonIdentifier. An open standard of identifying a user, not a standard that exists to provide a cross-site identifier. And if you do want to look at it as a cross-site identifier, it should be so only to the user, not to the sites. Connecting data between sites should be simple and painless to the user, but not done without permission.

    I have a strong issue with having the sites I signin to each having *automatic* knowledge of the identifier I am known by on all the other sites. Users should not have to take conscious effort to protect their privacy. This is why I advocate making this a strong recommendation, perhaps part of a "trustworthy provider policy." It would at the least highly discourage consumers from being able to make any assumption that they may be able to reliably match up data with another site.

2. The other side of the coin, is that on some sites I may want to "make my data public" -- freely linked with by other applications without question. This is where the "public identifier" idea might come in. The way it works currently for most providers. I could, on a photo site, want to allow the public to see that I, dcparker.myopenid.com, own these photos. In that case, I agree, I wouldn't really want an id like myopenid.com/user/139861 to be shared, it wouldn't make sense. Nor would it work on site other than the photo site (since the per-site identifier piece would limit that). Perhaps in that case I could instruct my provider to release my "public" id to the photos site instead, and perhaps provide a mechanism by which to match them up, if it had previously known me as myopenid.com/user/139861...

    I understand the desire to retain the possibility of matching up data. But it MUST be with the user's permission! In that case, simply let the OpenID provider serve out that mapping information on request, with the user's permission. Or with permission provide the user's "public id". (Another way to map cross-site information that would [probably] be entirely within the boundaries of privacy and trust but without user interaction, mentioned in PS, below)

3. Lastly, I don't understand some of the talk about public/private key pairings or digitally signing multiple accounts to one another. What I'm talking about is simply providing a unique id to each site, transparent to the user (the user enters the provider site, not his/her id), so that sites are not given too much power without the users' permission.

Otherwise, it looks like this is a spot that needs ironed out, even if nothing more than for our mutual understanding of the purpose of OpenID and some ideas of privacy and linking of data. Thanks all!

~Daniel

PS.

Consumer site A asks Consumer site B for data related to a user identified by idprovider.net/user/AAA.

site B asks idprovider.net for the mapping from ".../AAA at site A" to "my own id" for this user.

In transferring its data back to site A, site B will swap out its own id values for site A's id values, so site A never sees site B's id, nobody has to store mappings, one background web request is added.

[Aaron Cheung]

Re that, from me it was just an idea (for experiments) for the option to do it (privacy-enhanced seamless ux) together with the user (instead of transparent to the user).. for additional cross-session features some applications might want to have more control (eg., for accounting/audit/caching/expiry reasons).. certainly not required, but could be optionally provided..  For example, imagine the additional ease of p2p-app peering efficiency, or geolimiting access (like what hulu.com or upline.com once wanted to do to restrict service to a particular country) *if* there were a COUNTRY field in the tcp/ip stack of protocols.. meaning, i was (only) talking about some non-standard extensions, yet leveraging on what's already possible with the existing protocol (via an encrypted hash string in the url).. /ac.

[anders conbere]

Could you give me some examples of how the current system is (or could
be) abused to act in ways that the user isn't expecting? I think I'm
having a hard time simply groking the problem you're addressing.

~ Anders

[Daniel Parker]

OpenID could be abused in ways the user isn't expecting...

Reviewing the thread a bit I see mention that there is a bit of a controversy between generations. I fully agree that the younger generation allows and somewhat expects their data on the 'net to be public, and they generally trust websites (probably more than they should); and that the older generation is a bit more closed (sometimes too much), but rightfully asking for the security and privacy that should be granted them. So we have two opposing interests that introduce a complication in choosing default behavior.

1) The threat I am targeting is the threat that any two website who have my openid could, without my permission, match up my data between the sites which would be thievery: generating information about me from my provided data, that I did not ask to be generated. Any actions done on this "linking" data are unwarranted -- the creation of it, analyzing it, using it publicly or privately. The Linking of information is one of the links in the value chain of information, and deriving value from my data in this way may be outside my interests -- not that everyone is doing it, but that until OpenID, it was extremely hard if even possible to link data across sites without the user's permission; but with a common ID, it is all too possible.

2) The other thing needing addressed is this: The average user, when they learn about OpenID, should understand the implications. Take a look at http://openid.net/what/, with the perspective of a non-developer new to openid. Nowhere does it purpose to give the impression that your id is made to be global for the purpose of linking information about you. I've been read up on OpenID from the beginning stages of it, and I don't remember ever hearing "linking information" as a motive for OpenID from the group that designed it. http://openid.net/what/ explains that it is to 1) eliminate the need for different usernames across websites (single signin) and 2) allow the user choice in who they trust for identifying him/her. Notice the phrase, "OpenID is a lightweight method of identifying individuals...". Anyone more authoritative than I is welcome to correct me (and all the public-facing pages and wiki's, etc), but I believe OpenID's purpose is to offer single, decentralized, user-controlled signin; NOT to provide global id's. With where-I'm-coming-from clarified, what I want to say is, if the average user sees "Single Signin", we should not neglect to mention the implications of a global identity, and provide equal opportunity and pointers to choose a non-global-id OpenID (could just come through as two flavors of OpenID providers).

Both points come together: Some people will want a fully global ID by which they can "stamp" their information for the public to see; but just as many others will [want to] use OpenID for signin only, and know little to nothing about the possible compromising of their data ownership/privacy.

Both "modes" should be possible; both should be easy; both should be supported. But the pessimistic mode should be assumed by OpenID consumers, and the pessimistic mode should be recommended as it is the higher security and less-educated option. (pessimistic == automatic private per-site id)

~Daniel

PS. I use the term "data ownership" -- I define that to mean "having full control over and rights to any value derived from the data."

[Brett McDowell]

This seems like a conversation we should engage the OpenID Foundation in.  Are OpenID Foundation members engaged with DP?  

-- Brett

[Christian Scholz / Tao Takashi (SL)]

Hi!

> Proviso. Unless you want to be matched up. And I'd suggest that wanting
> to be matched up is the norm and avoiding it is the edge case.

Maybe because people didn't think about it. I at least know a whole
lot of people
who want to keep separate identities and if that's not possible that
IMHO the solution
is a very weak one.

You can do such service level portability with what I wrote up in the
technical docs but
for me that's really not far enough. We have "control" in our message
and I also really
would like to see this implemented.

-- Christian

--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com

Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T

[Julian Bond]

Daniel Parker <dcpa...@gmail.com> Wed, 21 May 2008 14:36:58

>Reviewing the thread a bit I see mention that there is a bit of a
>controversy between generations. I fully agree that the younger
>generation allows and somewhat expects their data on the 'net to be
>public, and they generally trust websites (probably more than they
>should); and that the older generation is a bit more closed (sometimes
>too much), but rightfully asking for the security and privacy that
>should be granted them.

OI! Young Man! Stop being Ageist! It's not a tension between young and
old. Although it may be a tension between Net Obsessed and Net
Indifferent.

ps. Tongue firmly in cheek. Except that the older I get the more pissed
off I get with ageism and especially the idea that "the kids just
naturally get it and old people don't or can't"

--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat

Store In A Cool, Dry Place

[Julian Bond]

"Christian Scholz / Tao Takashi (SL)" <tao.t...@googlemail.com> Thu,
22 May 2008 01:39:50

>> Proviso. Unless you want to be matched up. And I'd suggest that wanting
>> to be matched up is the norm and avoiding it is the edge case.
>
>Maybe because people didn't think about it. I at least know a whole
>lot of people
>who want to keep separate identities and if that's not possible that
>IMHO the solution
>is a very weak one.
>
>You can do such service level portability with what I wrote up in the
>technical docs but
>for me that's really not far enough. We have "control" in our message
>and I also really
>would like to see this implemented.

I'm tired of this but I don't want to get irritated by it. IMHO the
majority (by a long way) want to match identities across sites. This is
why web 2.0 properties like Friendfeed, Mybloglog, Facebook
applications, standards like XFN and so on have appeared. IMHO people
who want to have separate and private alternate identities are a small
(but vocal) minority. I don't want to exclude those people in the
thinking but I think that they are an edge case. I suspect that they are
better served by producing text guides to explain how to exploit the
technology while retaining privacy than by complicating the standards to
specifically support them.

--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat

[anders conbere]

I just don't see why openID in anyway hampers you from creating
seperate identities, it would simply require that the user create a
new openID for sites it doesn't want to give the ability to link in.
Right now people seem happy using the same username (or very similar)
across many sites, and the reality is that for many of those sites
there's a high degree of correlation between their users. That is, if
they wanted to they could probably link you up now... UNLESS... you're
already making new ID's for each site.

~ Anders

[Daniel Parker]

If you "should" be creating several identities, what's the purpose of Single Signin?

I'm seeing that some people (at least in these conversations) like OpenID because of Single Signin, and some people like OpenID because of the idea of a global public ID. All people will probably enjoy benefits from both. But we have to offer the combination of those that people want, and only what they ask for.

(People [even me] are happy using the same username across sites because it is not a reliable assumption that sites can go and link up data based on those usernames. OpenID, with a globally public id, provides basis for that assumption.)

I think it's logical for a user, when signing in to a new site, to by default simply be able to sign in without privacy concerns; but upon preference specify that my id on this site can be my public (and nicer-looking) id. This is just an issue of including the right language and message and distinctions in our Recommendations for OpenID Providers. Currently I believe there are several OpenID providers out there who have embraced the OpenID hype and have provided a service without giving one bit of thought to this issue that weasels itself past the outskirts of privacy.

- - - - - - - - - - - - - - - -

>>Reviewing the thread a bit I see mention that there is a bit of a
>>controversy between generations. I fully agree that the younger
>>generation allows and somewhat expects their data on the 'net to be
>>public, and they generally trust websites (probably more than they
>>should); and that the older generation is a bit more closed (sometimes
>>too much), but rightfully asking for the security and privacy that
>>should be granted them.

>OI! Young Man! Stop being Ageist! It's not a tension between young and
>old. Although it may be a tension between Net Obsessed and Net
>Indifferent.

Yes, I'm sorry. I don't mean anything against either generation's ideas, and I absolutely don't mean to force everyone into a stereotype! But your wording may be better. I just meant there are those (and I've seen this *mostly* represented by "levels of familiarity with computers-in-everyday-use") on two distinct sides, and of course those in the middle. I simply want to highlight the point that those who ask for security and privacy are not wrong to ask for it. I probably should be in the "younger" generation I spoke of, but obviously I am a strong proponent of the ideals the "Net Obsessed" asks for, so I'm an anti-example of my own stereotype. :)

>I suspect that they are
>better served by producing text guides to explain how to exploit the
>technology while retaining privacy than by complicating the standards to
>specifically support them.

Clarifications:

This whole discussion doesn't change specifications at all. What I'm pushing for is completely possible within the current specs. What I'm pushing, though, is that the general idea of OpenID seems to have been tainted by many developers who see things differently than many of the average people, and I think this is one of the biggest reasons for slowed public acceptance. I want to facilitate a discussion and hashing out of the topic, so that we can all see the same playing field, even if there are pieces neither "side" has seen before; and [currently] I'm asking for Recommendations to be added, that simply direct the current developer's implementation mindset toward the privacy that many users want.

~Daniel

[wavetheory]

The threat I am targeting is the threat that any two website who have
my
> openid could, without my permission, match up my data between the sites
> which would be thievery: generating information about me from my provided
> data, that I did not ask to be generated. Any actions done on this "linking"
> data are unwarranted -- the creation of it, analyzing it, using it publicly
> or privately. The Linking of information is one of the links in the value

> chain of information<http://liako.biz/2008/05/the-value-chain-for-information/>,

> and deriving value from my data in this way may be outside my interests --
> not that everyone is doing it, but that until OpenID, it was extremely hard
> if even possible to link data across sites without the user's permission;
> but with a common ID, it is all too possible.

What prevents two websites who have your e-mail address linking up and
sharing information right now? Generally the TOS of the sites and
concern over competitive advantage. I agree that OpenID should have
site-specific urls/tokens that operate behind the scenes. It seems
like OpenID allows for this and, indeed, is being implemented by
providers like Yahoo. Soon, your profile data will be relatively
centralized with fine-grained permissions control. I fail to see how
your potential scenario is a technical problem, or whether there is a
problem at all.

[Daniel Parker]

> I agree that OpenID should have site-specific urls/tokens that operate behind the scenes.

That's exactly what I'm targetting - behind the scenes is perfect, and it's possible -- not even hard to implement. But what makes it so hard to accept that it should be implemented?

> What prevents two websites who have your e-mail address linking up and

sharing information right now? Generally the TOS of the sites and
concern over competitive advantage.

I understand that. It's also a weakness, which make it all the more exciting that OpenID could fix that weakness. TOS is great, but sometimes not strong enough, and users almost never read them anyway, just expecting compliance with their general ethics. Concern over competitive advantage -- many times you'll have a competitive advantage *by* matching up data, not by keeping it safe.

The issue isn't that there are "hackers" waiting at the door for you to give them a key. It's the underlying principle of how identity and trust works. For the half of us who are happy having one public identity, or two or three managed identities, this doesn't apply. It's a question of identity and trust.

Identity: more or less, not only your contact details and who your friends are, but also what you've done and where you've been. It's being able to connect two things you've touched.

Trust: I don't give keys to my business to just anyone, even if I trust them. I only give keys to the people who have a need to get in (even then only if I trust them not to give keys to anyone else or let anyone else in). In the grand scheme of things, I like to trust people, but when it comes to something that affects more people than just me, I MUST prefer to trust technology over people. All standing arguments saying "What's the problem" still stand on a measure of trust for people. Yes, we do have to trust a third party with our authentication and identity, but I want the trust in my control: I want the ability to trust only the site that doesn't trust other sites without my permission.

OAuth does a great job of this. OpenID has spread too thin in what it can accomplish. We shouldn't have GlobalID and SingleSignin mixed together. Identity (OpenID) is different than data (OAuth). Identity is the connector of data, and therefore must be kept private in a different way.

~Daniel

[Jonathan Vanasco]

On May 21, 2:36 pm, "Daniel Parker" <dcpar...@gmail.com> wrote:
> OpenID could be abused in ways the user isn't expecting...
> Reviewing the thread a bit I see mention that there is a bit of a
> controversy between generations. I fully agree that the younger generation
> allows and somewhat expects their data on the 'net to be public, and they
> generally trust websites (probably more than they should); and that the
> older generation is a bit more closed (sometimes too much), but rightfully
> asking for the security and privacy that should be granted them. So we have
> two opposing interests that introduce a complication in choosing default
> behavior.

Generational tolerance isn't an excuse for poor privacy concerns --
and doesn't address the issue that large problems can and likely will
occur in the future.

The current climate of OpenID implementions reminds me of people
putting lead in childrens toys -- no one cared / noticed for years...
then all of the sudden everyone is all "Shit. That was a pretty stupid
idea".

There are two seemingly opposing interests:

1 - Users and Technologists want to be able to link information,
perform single sign on, and have a spiffy internet experience.
2 - People should have the security and privacy of linking that
information on their terms, and only to those people they specify.

Notice I used the word 'seemingly' opposing. It's not hard AT ALL to
offer both - a handful of people have been doing such. Many
implementors are either lazy or have ulterior motives and don't care.

> 1) The threat I am targeting is the threat that any two website who have my
> openid could, without my permission, match up my data between the sites
> which would be thievery: generating information about me from my provided
> data, that I did not ask to be generated.

Why do you think Google , Yahoo and Microsoft are backing OpenID and
Data Portability... or Comcast is jumping in by grabbing Plaxo? Out
of the kindness of their hearts? No, it's their advertising strategy.

> Both points come together: Some people will want a fully global ID by which
> they can "stamp" their information for the public to see; but just as many
> others will [want to] use OpenID for signin only, and know little to nothing
> about the possible compromising of their data ownership/privacy.

Just about everyone wants a fully global ID... sometimes even a few of
them... that list all the public things they do.

But they want that action of "stamping" their info - not having it
automagically opted in by a consortium of technology intersts or
people search algorithms.

Most people also want the single signon features...

But focus group someone, and then start asking them if its ok to bring
in more and more of their personal info, and they cringe.

> Both "modes" should be possible; both should be easy; both should be
> supported. But the pessimistic mode should be assumed by OpenID consumers,
> and the pessimistic mode should be recommended as it is the higher security
> and less-educated option. (pessimistic == automatic private per-site id)

Absolutely. It should have been like that from the start though.

[Daniel Parker]

Very well said, thank you. It really helps to have someone else restate and add thoughts, sometimes it's hard to understand just one lone voice.

~Daniel

[Paul Madsen]

I'll just note that Liberty Alliance did just this, ie started with the
'pessimistic mode' and built in a whole bunch of support for pairwise
identifiers (that support now available in SAML)

If you turn off those mechanisms you get the global ID mode

paul

p.s. of course, Stefan Brands will tell us that any claims a
browser-redirect SSO protocol (OpenID, WS-Fed, SAML etc) makes for
privacy are an illusion

--
Paul Madsen e:paul.madsen @ gmail.com
p:613-482-0432
m:613-282-8647
aim:PaulMdsn5
web:connectid.blogspot.com

[Daniel Parker]

Ya know what'd be a killer provider? One that automatically provides both site-specific openid, and email addresses like 234hp9w[a site-specific-id]@provider.com that forwards to the user's email. And optionally at signin allows the user to provide his/her public information, openid username.provider.com and email user...@gmail.com instead.

I'll probably have that in a few months just working in my spare time, all you who want better OpenID privacy keep your ears tuned! :)

~Daniel

On Tue, May 27, 2008 at 4:25 PM, Jonathan Vanasco <jona...@findmeon.com> wrote:

[Jonathan Vanasco]

On May 29, 3:23 pm, "Daniel Parker" <dcpar...@gmail.com> wrote:
> Ya know what'd be a killer provider? One that automatically provides both
> site-specific openid, and email addresses like 234hp9w[a site-specific-id]@
> provider.com that forwards to the user's email. And optionally at signin
> allows the user to provide his/her public information, openid

> username.provider.com and email usern...@gmail.com instead.

We offered that most of that in October 2006. No one wanted it. The
VCs and experts we tried to solicit hated it.

Technologically, the email is a fucking nightmare.
I tried to get the email portion running multiple times with no luck
in stability - it just failed miserably on our stress tests. We were
using exim ( with perl or python compiled in to try and get better
speed ) but it became too resource heavy -- every 'user' of our system
had between 5 and 25 'valid' email addresses automatically created
@user.findmeon.com ... which just slammed the sql and memcached
stores. Then we started using fake spam bots. Even with agressive
blacklisting, greylisting, tarpitting/teergrubing and all sorts of
merriment, the solutions would become almost as bad - sucking down CPU
and eating up bandwidth connections.

If you're running a large cluster - you can do it a lot easier. But
if you're a startup, you can't scale it more than 20k users.

Our workaround was to develop a stack with our RapidRegister ,
QuickList and network API.
RapidRegister: A widget - or Login->Redirect - would generate a new
site-specific OpenID identifier that links to no information on our
website. It's basically /dev/null
QuickList: A lightweight API that does a 2way bind between the
network's ID and our ID , and includes an approval where the user opts
in to link other specific identity Identifiers and Profile items
API: would push info back and forth, and allow the partner network
to send messages

It solved the problem and was slick, but Sand Hill Road disagreed.

On the system we took down this fall, one could generate a new site-
specific open-id through a widget or non-identity-showing open-id
login.

[Daniel Parker]

Very interesting. Interesting indeed.

First of all, that VC's didn't like it ... I guess sometimes people actually don't like the best technology. It does help us to make it more user-friendly, but sometimes you just have to push ahead and wait for the acceptance that comes later.

I would think of the email addresses as being provided simply for the use of the consumer site -- you wouldn't advertise it to the user. The user might never see it, it's just a way that the consumer site can communicate with the user without knowing the user's real email address. What if you didn't need to store any email mappings for a user, it just works the same way as the site-specific id, being a hash of a user-secret and the consumer domain? Basically, you accept dynamically map emails to users based on their originating domain. A transparent white-list approach, in a way. (Of course there are enough troubles of validating where the email was actually sent from. But that probably wouldn't be an incredibly large problem?) As far as I can tell, you really wouldn't be able to be a target for spammers at all, since they'd have no chance of getting through. :)

Does that sound impossible?

~Daniel

[Jonathan Vanasco]

On Jun 2, 10:32 pm, "Daniel Parker" <dcpar...@gmail.com> wrote:
> Very interesting. Interesting indeed.
> First of all, that VC's didn't like it ... I guess sometimes people actually
> don't like the best technology. It does help us to make it more
> user-friendly, but sometimes you just have to push ahead and wait for the
> acceptance that comes later.

Off-list, I can give you a list of luminaries and VCs that are 200%
behind DP now and ridiculed these concepts 2 years ago. It's part
user-friendliness, and a larger part reluctance - technology like this
costs them ad impressions and user-lock, and they need to know they're
getting something in return.

> I would think of the email addresses as being provided simply for the use of
> the consumer site -- you wouldn't advertise it to the user.

> never see it, it's just a way that the consumer site can communicate with
> the user without knowing the user's real email address.

It's far simpler and more powerful to do via an API -- among other
things, you get automatic confirmation of 'receipt' ( versus tying
into VERP systems ).

> What if you didn't need to store any email mappings for a user, it just works the same way as
> the site-specific id, being a hash of a user-secret and the consumer domain?

Well you still need to validate and associate the hash. On a large
system with tens of thousands of accounts, you're looking at an
scaling the db lookups to validate the hash on an average factor-of-
ten.

> Basically, you accept dynamically map emails to users based on their
> originating domain. A transparent white-list approach, in a way. (Of course
> there are enough troubles of validating where the email was actually sent
> from. But that probably wouldn't be an incredibly large problem?) As far as
> I can tell, you really wouldn't be able to be a target for spammers at all,
> since they'd have no chance of getting through. :)
>
> Does that sound impossible?

The best way to protect against spammers would be to use some sort of
domain partnership program, where there's some sort of hash or
checksum approach per domain. it would still require a quick db
check, but you're likely to profit from a lot of caching.
unfortunately, it would require the participation of the domains...
and at that point, you might as well go for an API.

None of this is impossible... it's just a matter of probabilities and
likelihoods.

With <=10,000 users, I think a generic email system could work.
At >=20,000 users, you're deep in experiencing db issues on volume.
At any number of users, you can expect spam to be a problem...
especially if you're doing some sort of published ID or a 'formatted/
templated' one. The spam processing and anti-spam fighting apps will
create scaling issues for CPU. And you still have issues of false-
positives.

Maybe a possible solution would be to handle email only for domains
where API integration hasn't been started?

I like APIs, because you can do a shared-secret to prove a message is
from their applications (not just their IP block)