Pseudonyms for Privacy

Title: Pseudonyms for Pairing

Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page

Session: Tuesday, Session 4, Space C

Convener, Note Taker: Jay Unger

Tags:

Pseudonyms, OpenID

Discussion Notes:

The meeting was attended by about 20 people.

• Jay Unger gave a short presentation about Pseudonyms. http://www.slideshare.net/JayUnger/iiw-11-pseudonyms-5771938
  • In this context he defined a Pseudonym as being unique value returned from and authentication transaction that was related to the combination of user and relying party.
• There seemed to be general consensus that Pseudonyms are good way to preserve user -privacy / -centricity across many Relying Parties
• Jay suggested that Pseudonym should be the default information returned from an OpenID authentication transaction and the ONLY information returned without specific additional requirement of the Relying party.
  • There seemed to be general consensus for this notion that Pseudonyms should be the default.
  • However there is tension from Identity providers like social networks and portals to do just the opposite. The direction that Identity providers like Google and Yahoo seem to be headed is to return globally unique Pseudonyms that are only related to the Identity provider and user and NOT unique to the combination of user and relying party. This explicitly allows user correlation across Relying parties.
  • The user correlation feature that some Identity and Relying party groups seem to desire could be accomplished using attributes specifically designed for that purpose. Such attributes would essentially be Pseudonyms that were only unique to the user and perhaps Identity provider. If these attributes were generated and treated separately from Pseudonyms that are Relying Party specific, then users could decide which of the two different types of attributes that wanted an Identity provider to return and thus control the level of “identification” they wished to express with a particular relying party.

• Jay also discussed a use case and requirement to support use of the same Pseudonym presented by different Identity Providers, for the same user’s authentication with a particular Relying party. This, for example would allow a user to associate the same profile for that Relying party with both their personal and business userid.
  • This was thought to be a difficult requirement since in this case the Pseudonym generated by one Identity provider would be employed by a second Identity provider.
  • In the absence of attributes (assertions) being digitally signed by the issuer(in this case the Identity provider that created the Pseudonym) many Relying parties are judging the value of a returned id based only on which Identity provider returned it.
  • For example Yahoo and Google presently return a Pseudonym that is related to the combination of the user, Relying party and Identity Provider realm. They do not expect to get a Pseudonym they generated to be presented by any site other then themselves and would not readily trust their own Pseudonym (though I don’t necessarily know how they would tell) if it where received from another Identity provider.
  • Jay outlined a method from transferring a Pseudonym related to a particular RP (relying party) from one IdP to another:
    • The user would first authenticate to a site (RP) with either an existing IdP that they had already used to register at the site or a new IdP that the site had not yet seen.
    • That authentication would either present a Pseudonym that either was either already recognized if the user was already “registered” with the site (RP) through that IdP, or not if the user had not used that IdP to register.
    • If the Pseudonym was not recognized by the site (RP) the user would have the option to continue registration with site an generate a new registration (and a different identity) or to try to associate an existing registration with the site from another IdP.
    • If the Pseudonym was recognized the user would be logged in and would be able to request association of their existing registration to another IdP (by selecting an account or profile management function at the RP site.)
    • If the user wished to associate their registration with another IdP The RP site would permit the user to select another IdP (either via URL or NASCAR selection) and then request an authentication from that second IdP. The second IdP would return their Pseudonym.
    • The user would be permitted to select whichever IdP and Pseudonym that the user desired to retain as their identity attribute associated with the Relying Party (either from the first IdP or the second IdP).
    • A request would send the Pseudonym chosen from whichever IdP the user selected to the other IdP to replace the Pseudonym they would respond with for that site (RP) in the future for that user.
    • The user could remain logged into the RP site with either or both IdPs.
    • Assuming that these pseudonyms are essentially attributes (in future OpenID protocols) and that they are digitally signed both by the agency (IdP) that created them and probably by the agency presenting them in response to an authentication request, such pseudonyms would derive authority both from the IdP that originally created it and from the IdP that was presenting the attribute to the RP.