If you haven't seen the announcements for the Internet Identity Workshop (IIW) floating around the identity listservs, it's happening Nov. 3-5 at the Computer History Museum. A lot has happened since the last IIW in May and I'm excited about the progress that has been made in the intervening months.
Thinking back to past IIWs it's great to see the progression of topics at IIW from geeky syntax and protocols to solutions and solving the problems from a user's perspective. With the recent developments around "webfinger" and XRD, some of the "glue" pieces are coming together.
I believe the next core issue to tackle in "Making it all work" is the user experience. To date we've been solving the problems mostly from a functionality perspective. However, just being "functional" isn't good enough for the average consumer. We need to make it easy and coherent (not a trivial task). By easy, I don't just mean "there aren't too many clicks" but rather a user experience that proactively helps the user with the tasks they need to perform. There are lots of nuances in the identity space and the average user doesn't grok them, so the technology has to help the user make the "right" decision.
I'm expecting discussions like this to be a key part of IIW #9.
Internet Identity Workshop
Registration
Monday, August 31, 2009
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.
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.
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.
- User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
- The user is redirected to their consumer LOA1 credential provider and logs in
- The user is redirected back to the govt web site with an LOA1 credential
- The user interacts with the web site
- 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
- The user arrives at the new site and does not have a LOA2 credential
- The site informs the user that they need a more secure credential and that they can get one from the following locations
- The user selects one of the providers and is redirected to that site
- 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)
- The user selects their current LOA1 provider (the one they used when logging into the govt site)
- 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
- The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
- 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.
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...
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 ...
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...
I'm not sure which method I like better. Maybe others have better solutions. Thoughts?
Update: Corrected my ProtectServe typos:)
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...
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.
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 ;-)
and I realized that my good friend is planning the conquering of the world ;-)
Saturday, February 14, 2009
Happy Valentine's Day
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.
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...
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.
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.
Subscribe to:
Posts (Atom)