Showing posts with label Privacy. Show all posts
Showing posts with label Privacy. Show all posts

Thursday, September 23, 2010

Privacy across Social Network aggregation

Social Network aggregation is a great personal service that allows me to see updates from all my social networks in one place. There are a number of services that provide this functionality: chi.mp and AOL Lifestream to name two. As long as I'm the only one viewing these aggregations, there are no privacy concerns.

However, the problem arises when content is shared (cross-posted) between social networks and then re-aggregated by the social aggregation service. Take the following scenario as one possible use case.

Alice participates in 3 social networks, statii (a real time micro blogging site), snaps (a photo sharing site), and frendz (a social network of my personal friends). In addition, Alice uses a social network aggregation site called socialview to give her a global view of all her social network activity. All of these social networks allow Alice to establish connections with her friends within those networks. Each of the social networks has it's own privacy mechanisms that allows Alice to share information publicly, or just with a certain set of friends. Even socialview allows Alice to establish relationships with other socialview users and share their aggregated social network activity streams. In addition, socialview allows Alice to cross-post status updates to both statii and frendz.

In this example, all of Alice's micro blog updates to statii are public. In addition, most of the photos she uploads to snaps are also public. On frendz, Alice is a little more careful and only shares information with friends. She does allow friends-of-friends to view her updates and any comments her friends leave.

Now, let's say that Alice uses socialview to post a status update to both statii and frendz. Let's also assume that Alice has decided that all her updates originating from socialview should be public. When Alice's status update appears in frendz, her friend Bob thinks it's relevant and leaves a comment in frendz on her status. Then Socialview, during it's normal aggregation cycle, sees the new comment from Bob and adds it to Alice's aggregated view.



This is where it finally gets interesting. Should Bob's comment be made public (given that Alice's privacy settings at socialview state that all her posts are public, and Bob is commenting on a "public" post?) or should his comment be visible only to Alice (because Bob didn't know he was commenting on a public post).

What I think is missing is a "visibility" scope attribute that needs to be attached to the activity as it navigates across social networks. In the above contrived example, this would allow frendz to make it clear to Bob that Alice's status is really public. It would also allow socialview to honor Bob's privacy settings that he only shares comments with friends when aggregating his comment back into Alice's aggregated view.

Friday, March 12, 2010

OpenID 2.0 Provider support live @ AOL

I'm excited to announce that the AOL Identity Services team has fully deployed OpenID 2.0 Provider support. Directed identity flows are now enabled so just entering 'aol.com' into an OpenID field will start the authentication flow. In addition to directed identity, this release also supports "check immediate" flows, SREG, AX, UI (popup browser), PAPE (as required by the ICAM OpenID 2.0 Profile) and of course the ICAM OpenID 2.0 Profile itself.

We have also improved the UI making it much cleaner and easier to follow. One feature of this new UI is a page that allows the user to choose, when first visiting a new site, whether to use their public OpenID (http://openid.aol.com/<username>) or an opaque one. Of course, this choice isn't necessary if the user provides the relying party their full OpenID or the relying party specifically requests an opaque identifier (via PAPE policy). I'd really appreciate feedback on whether this "privacy" feature is helpful to users or just adds more confusion.

In addition to the existing SREG support, the same attributes will be supported via Attribute exchange. There is equivalent support for the http://axschema.org URIs but only partial support for the Information Card URIs as there weren't direct equivalents for all of the attributes. Here is what is currently supported.

http://axschema.org/namePerson/friendly
http://axschema.org/contact/email
http://axschema.org/birthDate
http://axschema.org/person/gender
http://axschema.org/contact/postalCode/home
http://axschema.org/contact/country/home
http://axschema.org/pref/language
http://axschema.org/pref/timezone

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country


Suggestions or requests for specific attributes are always welcome. One point of clarification regarding email addresses and verification. The current implementation defaults the email address to the user's AOL provided email address but does allow the user to change the value returned to the relying party.

While there is still a lot to do, it feels really good to finally reach this milestone.

Friday, August 14, 2009

User experience and Levels of Assurance

The US government recently (Aug. 10th) held an Open Government Identity Management Solutions Privacy Workshop to discuss Trust Frameworks, Levels of Assurance and Privacy. At this workshop the government introduced a process for the adoption of any identity technology and a process for the adoption of any Trust Framework as managed by a provider (e.g. a Trust Framework Provider [TFP]). Both documents can be downloaded from the above link.

One of the key points brought out at the meeting is that user experience (UX) is critical as users navigate government web sites that potentially require different levels of assurance (LOA) (see OMB M04-04). While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over. I believe UX and transitioning between levels of assurance is one of the critical issues to solve.

While specific technologies may be restricted to certain levels of assurance, the user experience should be agnostic to the technology required to implement any specific use case. In this context I'd like to propose the following multi-LOA use case as one possible way to provide a good user experience.

  1. User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
  2. The user is redirected to their consumer LOA1 credential provider and logs in
  3. The user is redirected back to the govt web site with an LOA1 credential
  4. The user interacts with the web site
  5. The user clicks on an option on the web site that directs them to a new site (or a service within the existing site) that requires a LOA2 credential
  6. The user arrives at the new site and does not have a LOA2 credential
  7. The site informs the user that they need a more secure credential and that they can get one from the following locations
  8. The user selects one of the providers and is redirected to that site
  9. The LOA2 provider asks the user if they want to use existing LOA1 providers as a factor in the LOA2 credential
    • here I'm thinking that an LOA1 credential could be used in bootstrapping to the LOA2 credential)
  10. The user selects their current LOA1 provider (the one they used when logging into the govt site)
  11. The user goes through some identity proofing process (note that this could happen off line if necessary).
    • The point is that the user ties their LOA1 identity to the LOA2 provider. This helps with seamless transition between levels
  12. The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
  13. The user enters the one-time-pin and the LOA2 provider issues an LOA2 credential and redirects back to the requesting web site


I'm sure I've left out some critical steps or places where the above does not comply with assurance framework requirements. I would appreciate feedback as to whether the general idea is viable. I would hope that one goal of this effort would be to protect the user (as much as possible) from having to increase the number of identities they manage.

Tuesday, February 13, 2007

OpenID: Not all Chocolates and Roses

There has been quite a bit of hype regarding OpenID within that last few weeks. One of the biggest announcements is that Microsoft will work to support OpenID with its Cardspace card selection metaphor. While there are not many details about how this will work, this is still very good news for the OpenID community. There are other major identity players also working to support OpenID for their customers.

I would, however, like to bring some practicality to all this hype. OpenID as an identity system is perfect for the blogosphere and any publicly published content. It provides single-sign-on and auto-correlation across all comments, blog posts, picture galleries, etc that I publish. However, it's the auto-correlation part that causes problems when I'm NOT wanting to operate on the web in a public manner.

There are many tasks I do online that I do not want to ever by public (e.g. my banking site, purchasing history from Amazon, etc). While OpenID provides the single-sign-on benefit I desire even for these kinds of tasks, it also inherently allows for the correlation of my activities by those sites without my consent. This is definitely NOT user-centric.

The problem this creates is that most users will not understand the impact of using a correlatable identifier at all the sites they interact with and will leak privacy information in the process. I do want to note that the OpenID 2.0 draft spec addresses this issue by allowing an interaction method where the user can allow the OpenID Provider (OP) to pick a unique identifier for them. The user will then be known by that identifier at that site. However, my concern is that while this method is supported, it's not getting much traction in the industry.

As OpenID becomes more main stream it will be important for OpenID Providers to address not just the social-web tasks of users, but also the personal tasks of users and provide appropriate privacy protection.

Tags: OpenID, Correlation, Privacy