Friday, April 03, 2009

ProtectServe and "Social relationship" authorization

In a post today, Paul highlights a form of authorization that is not yet fully fleshed out in the ProtectServe architecture...
Ultimately, I think User's need to be able to define authorization rules for their identity attributes in terms of both

1) the requesting actor (Consumer in OAuth/ProtectServe, WSC in ID-WSF)
2) an individual with some defined social relationship to themselves

ProtectServe's AM is designed to simplify for User's the definition and management of the first type of authz rules, Liberty's People Service the second.

Of course the mention of ProtectServe is referencing the recent work of Eve Maler and team regarding a proposal to help simplify authorization management for users in the "distributed web".

I believe that it should be possible to extend the Authorization Manager (AM) to leverage social relationships as a mechanism for the user to control access to protected resources. One of the use cases Eve mentions in this post is ...
Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group

Paul correctly points out that the Liberty Alliance People Service is built for just such a task. As it turns out Portable Contacts provides very similar functionality and is based on OAuth (the same base as ProtectServe). The Portable Contacts (PoCo) specification allows for grouping of contacts in an arbitrary manner using tags so the examples Paul gives are easily mapped. One missing feature of the current PoCo spec is that it doesn't support "membership queries" which means that more information is leaked to the Service Provider than necessary.

Let's look at this use case in more detail. Assuming that Alice has created a resource at her photo service for the vacation photos, and also assuming that Alice has identified the desired set of individuals in her PoCo service with a tag of 'VacationPhotos', all Alice needs to do is associate this tag with the desired resource. So let's assume this is possible within the AM. Finally, let's assume that Bob is one of the individuals with a 'VacationPhotos' tag in Alice's PoCo service.

The basic flow is that Alice sends Bob the link for the protected vacation photos. Bob clicks on the link and is taken to the photo service via his browser. The photo service check with the AM to determine whether the resource is protected or not. Since the resource is protected, the photo service asks Bob to authenticate. Based on Bob's authentication, and his membership in Alice's 'VacationPhotos' group, Bob is given access to the photos.

The interesting twist with this particular use case is that the "Consumer" is really a user (i.e. Bob) who wants to view Alice's vacation photos. So when Bob tries to access the vacation photos resource that Alice shared with him, he accesses the service provider directly. At this point the SP checks with the AM regarding the authorization rules for the resource. However, Bob doesn't have a Consumer "token and secret" with which to sign his request to the SP. Instead he is accessing the SP directly via his user-agent. What Bob can do is authenticate himself to the SP using some authentication means. This is necessary as an identifier is required to determine membership in Alice's 'VacationPhotos' group.

This leads to the question of who should manage the relationship with Alice's PoCo service to do the "membership" check? I can see two options...
  1. The AM maintains the authorization requirement (e.g. consumer must be member of Alice's VacationPhotos group) but the SP does the actual membership check. In this model the SP needs to set up a ProtectServe based relationship with Alice's PoCo service. Then when the SP authenticates Bob and has an identifier for him, it can check directly with the PoCo service determining membership based on the "contract" received from AM. This means that the SP must be able to interpret and process the "contract" on behalf of AM.

  2. The AM maintains the authorization requirement and also does the membership check with the PoCo service. In this model, the SP will need to forward Bob's identifier to the AM in order for the AM to perform the "membership" check and determine the state of the authorization. Or the SP could redirect Bob to the AM but I would that such a UX would most likely confuse the user. I do think there is a interesting privacy question on whether the SP should be allowed to forward Bob's identifier to the AM without Bob's consent.


I'm not sure which method I like better. Maybe others have better solutions. Thoughts?

Update: Corrected my ProtectServe typos:)

Thursday, March 12, 2009

Betrayed...

I've been wondering about the current economic crisis and where its headed; who's behind all the problems and is there an end game? Then I saw this...


and I realized that my good friend is planning the conquering of the world ;-)

Saturday, February 14, 2009

Happy Valentine's Day


Red & White for Valentines Day, originally uploaded by GFletch.

For the last two year's I've posted a picture from this bush in our front garden on Valentine's Day. The last two years there has been snow or ice either on Valentine's Day or the day before. However, today is bright and sunny and no snow. So this picture comes from the last week in Jan.

Friday, February 13, 2009

OpenID UX Summit Musings

First, a huge thank you to Facebook for hosting the summit and live streaming the event. I wasn't able to attend in person, and being able to watch the wrapup and presentation of the OP and RP breakout groups made missing the event bearable.

Second, I think that for the OpenID Provider UI there needs to be a way for a RP to influence the UI. Basically, there would be one UI that is generic and totally related to the OP. This would be the default UI shown in the pop-up browser window. However, if the RP has a relationship with the OP, there should be a way for the RP to invoke the pop-up browser window such that some of the UI is customized to the RP. One feature I really like of Facebook Connect is that it gives clear UI context to what the user is doing.

I know for some OP's, its important to only allow customization from RP's that are in a relationship with the OP. This could easily be accomplished by using 2-legged OAuth and associating the UI customizations to the OAuth Consumer Token. The RP would then construct the 2-legged signed URL and load it into the pop-up browser window. The OP would verify the signature and make the necessary customization.

Here's one mock that should look familiar... (my apologies if this is what was discussed and drawn on the whiteboard. I couldn't "read" the whiteboard over the live stream. Final caveat; I'm no UI designer :)

In the default case, the RP's realm string would be displayed along with some generic text and a generic image representing the RP site. The OP image on the right would of course be unique to the OP.

In the case where an RP could provide customizations. The RP realm could be replaced by title text, the description could be specific to the relationship the user is establishing with the RP, and the RP image could be specific to the RP. To make these customizations work from a security perspective, the RP would need to obtain an OAuth Consumer token (and secret) via an out-of-band process (normal OAuth). The RP would then provide the OP with the necessary customizations during this provisioning process. These customization could include, RP realm, UI title text, UI description, and RP image. At UI display time, the OP retrieves the necessary customizations based on the OAuth Consumer token and displays the UI to the user.

With this kind of a model, the UI stays consistent and familiar to users, but also provides RP's with some ability to customize the content to their needs.

Friday, January 23, 2009

OpenID protected sharing at chi.mp

I got a very pleasant surprise today when reading the Chi.mp release notes for release 1.9. The following extracted from the email...

OpenID. Your visitors can authenticate with their OpenID to see privileged content on your site.


I was very intrigued with how they provided this support based on my desire to see OpenID used specifically for this purpose. I have a previous blog entry on the topic here. Basically, Chi.mp uses the concept of "Personas" to segregate content in any way the user chooses. Then contacts are assigned to specific "Personas". As yet, I have not been able to find a way to assign a contact to more than one Persona but that doesn't really affect functionality.

Another very nice feature of their implementation is that if a user goes to my public profile page and logs in with their OpenID, I'm notified that the user has attempted to connect with me. This is a very nice interface as Chi.mp uses SREG support to collect information about the user. Now I can review the "connect" requests and had them as contacts assigning them to a Persona (if I choose). You can try this out with my Chi.mp profile here :)

The only problem I ran into was trying to add a contact via the web page because there was no place for me to enter that contact's OpenID. I'm sure this can be added easily.

Props to Chi.mp for moving beyond "security by obscurity" when it comes to protected sharing of personal information, and also not requiring all my friends to create a Chi.mp account.

Monday, December 08, 2008

Social Networks and Strong(er) Auth

I've been thinking about strong(er) authentication mechanisms recently and the slow uptake by the mass market. I was registering for an online brokerage account recently and was required to enter an email address. I thought through the many email addresses that I use and decided to use the one that has a strong auth mechanism attached.

One of the reasons for this decision is that my ever expanding Facebook world has a lot of information about me that might or might not be relevant to a "password reset attack". I recently found a bunch of childhood friends on Facebook and that has been wonderful. However, it also means that all the information about elementary schools attended, childhood friends, etc is exposed to all my other friends on Facebook. From an information perspective, I don't have any problems, but it does concern me from a security perspective.

Rather than think through what information is available on Facebook, and whether any of that information was used with the "Security Questions" for the email account, I chose to pick an email address that can only be accessed via a 2nd factor authentication mechanism.

So, my question/thought is, "Could social networks be the forcing function that drives consumer adoption of strong(er) auth technologies?"

Wednesday, December 03, 2008

Is it really aggregation vs federation?

In a post this past Sunday Om Malik suggested that user's want aggregation not federation. While I totally agree that user's want aggregation (e.g. having all their relevant information in one place) I don't believe aggregation is in conflict with federation. Rather the two concepts are orthogonal.

I associate aggregation with API access to my data distributed across the web. The exception is closed networks like Facebook that provide all the services within a walled garden environment. So for aggregation to work in the "open web", it must be able to access my data whereever I've chosen to place it. This requires explicit user consent (ala OAuth) for the aggregator to access my personal data at different services.

Now in order for me to grant consent, and for the aggregator to be able to access my personal information, I need to authenticate to the service provider of my data. This authentication step is simplified by using federation (e.g. an OpenID valid at all my different service providers).

So federation really enables a safer, more secure, aggregation capability for users.