At the Internet Identity Workshop 2009A

wow it's been a long time since I've last blogged. Last couple of months have been quite busy with couple of projects on hand. I've almost lost track (other than checking from OpenID and OAuth mailing lists once in a while) of what's going on in the Identity world outside of Amazon. So looking forward to get upto speed on what's going on in the Identity world and also catching up with fellow technologists from other companies.

Concerned about phishing ?

With all the swirls going on about phishing, Twitter APIs and OAuth - I just wanted to say - user education and awareness is the only way to solve phishing completely. No single technology can stop users from getting phished - unless the user knows what he/she is doing. Even websites using the out of band authentication and some OTP technologies are prone to phishing - an attacker can simply proxy the requests between the user and the real server. What technology can do is to make it easy for the users to learn how to protect themselves from getting phished.

OAuth just does the same - it introduces a consistent way to authorize clients to do something on behalf of a user, with the user's permission and not ask for their login credentials. Yes one might argue that malicious clients can spoof as the provider and phish for user's credentuals, but given that most of the providers allow SSO and session persistence, a user would still get alarmed if he is asked to provide his login credentials again.

Cardspace/Infocard selector provides a better security model against phishing by providing a way to completely eliminate the need for passwords. But if the Identity Providers (STS) still require Username/Password claims even with their managed cards, their users are still prone to phishing attacks.

I would recommend everyone to read the User Interface guidelines written by the Web Security Context working group in W3C.

2009 The Year Of ....

well everyone is predicting what's gonna happen in 2009 so thought why not me too :-)

Nope, I am not going to predict what technology is going to be widely adopted over another, which company will succeed in their online identity and data portability strategies, etc.... to be frankly I don't care. :-)

2008 has been a good year for Identity (Management and Access Control) and I think it will continue into 2009 with more emphasis on the following things:

1. User Experience and Value to End Users - I am one of those who say "my mom knows what email is but doesn't know what SMTP/IMAP are" and I want to see the same in online Identity world. Also I am strong believer that SSO alone doesn't carry many benefits to the end users unless there is some data associated with user's Identity that can be shared across different sites/services. IMO - these two together will play a major role in bringing several Identity related technologies into the mainstream.
   
2. Interoperability - not just between services/providers but also between various protocols and technologies in the Open (Web) Stack so they can be all stitched together seamlessly and effortlessly to bring better UX and value to end users.

Anyway eager to see what 2009 has for us and looking forward to work on even more interesting things.... and also very eagerly looking forward to hear my daughter (15m old) talking.

Happy and a Prosperous New Year Everyone !

Open User-Centric Connect ?

Just wondering if anyone started working on building an Open Source Connect-like application using the Open Stack (OpenId, OAuth, PoCo, OpenSocial, etc.) that provides users "control" on what Service Provider they want it to use. Or is Google Friend Connect going to become an Open Source project ?

Basically IMO - it should be a collection of client side Javascipt, HTML/CSS and server side php/java/.. code, which can be deployed by any Web Site. It should let users configure where they want their activities should be posted to, where to bring their contacts/friends from, etc..

Ofcourse all this should be done only using a combination of open standards like OpenID, OAuth, PoCo, OpenSocial, etc..

Thoughts ?

Static OpenID Associations !

One of the things that I have been thinking about recently is about what changes we would need in OpenID to make it easy to build something that provides seamless user experience like FBConnect (just user authentication not sharing user data like friends list, feeds, etc.).

Of course, with the existing OpenID 2.0 spec, it's quite easy to do it (using a combination of checkid_immediate and checkid_setup calls) but the RPs still need to do some heavy lifting in terms of setting up their servers, databases and database replication, etc.. to run on a farm of servers for scalability and performance. (for example storing and sharing discovery, associations and nonce verification information on multiple servers across different data centers and not to mention issues around enabling outgoing http connections to fetch discovery and associations info)

We could argue that the RPs can just use the check_authentication call to OP to verify the assertion but this adds up unnecessary additional latency in the overall authentication process.

And when it comes to enabling SSO with in trusted circles using OpenID, the dynamic discovery and association steps seems unnecessary. Usually trusted circles are limited in size and are used to sharing keys and secrets (meta-data) in some other offline provisioing process anyway.

So with those in mind I wonder if it makes sense to propose an extension to OpenID that would allow OPs and RPs in a trusted circle to establish static associations such that the RPs can just host a simple php/servlet/perl/.net/etc.. handler that validates the assertion returned by the OP using the stored association information locally.

It goes something like this

• Allows an RP to preregister with an OP to get it’s own association data.

• RP provides it’s preferred association type (HMAC-SHA1/256), and realm

• OP SHOULD do the necessary checks based on their business relationship to make sure the realm provided matches the RP , which is out of scope of this extension

• OP generates and provides assoc_handle, mac_key and expires_in

• RP uses the assoc_handle in the checkid_immediate and checked_setup requests.

• OP MUST always make sure the return_to url matches the realm exchanged during the offline provisioning process – not the realm passed in as a request parameter.

• OP MUST sign all the positive assertions with the mac_key corresponding to the assoc_handle passed in by the RP.

• If a given assoc_handle is expired, OP MUST fail the request (both immediate and non-immediate) with an openid.mode value as “expired_association” along with the expired association handle value as invalidate_handle parameter.

• RP MUST verify the assertion signature locally (must not send check_authentication request to OP)

• RP MUST make sure the timestamp passed in the response_nonce is within an allowed time period (say 5 mins)

  1. If the RP can do regular nonce checking (to make sure it’s only used once) then it SHOULD do so instead of just checking for the allowed time period as this exposes the replay attacks for a small window of time.

  2. Alternatively RP MAY sync it's clock based on OP
     

• RP extracts the user’s identity provided by the OP as per the OpenID specification.

To implement this all an RP would need are

• a few config file entries to provide association handle and mac_key to the application code
  
• a simple OpenID handler (php/perl/servlet/etc..) that uses the association information from config file to generate OpenID Server redirect url to request authentication (which can be cached as the assoc_handle doesn't change) and to verify the response from the OP (validate signature, nonce, etc..)

Now compare this with what it takes to become an RP with current OpenID2.0 spec.

Of course I know this is defeating the original purpose and intent of OpenID to provide authentication framework for the internet, but given that several people that have done various user experience analysis and finding that OpenID is more useful and meaningful to users when the RPs provide OP specific login buttons anyway (Login with Yahoo, Login with Google, etc..), would supporting something like this be way off the original intent ? Since this will be an optional extension, people who want to support any OpenID out there can still do it, while others who only care about SSO with a few trusted OPs (that they have business relationship with) do not need to reinvent the wheel.

Also another thing to keep in mind is for other apis/protocols (like OAuth) the RPs would need to share consumer information (keys and secrets) anyway.

Thoughts ?

Account Recovery for terminated OpenIDs

Wells one question that always comes up when talking about becoming an RP is - what do we do when the OP that our users chose to use, shuts down it's OpenID support ? The answer has always been - well collect your own credentials (which in most cases is a password, because no one wants to collect lots of PII info for online account recovery) so you can let the users recover their lost accounts if necessary in the future. Then the next question comes - well then why do I need to support OpenID and more over it's not solving the original goal of reducing the number of passwords the users have to remember.

Can all OPs provide 99.9% uptime SLA ? Or should every user on the internet have his/her own domain that delegates to a trusted OP and can be changed by the user if necessary ?

Any other thoughts ?

all set for Internet Identity Workshop

Just arrived in bayarea to attend the IIW from tomorrow. Missed all the fun today but the next two days is when things start getting more serious. Looking forward to participate in various discussions, learn and hear about things related to Identity and Authentication from others and of course meet some good old friends and great technologists from other companies.

I am in particular interested about things happening in the OpenID UX improvements side and also to talk about UX improvements in OAuth for mobile/client apps. It's been a long time (June 26th) since we started talking about OAuth spec updates covering very important usecases at the OAuth Summit - so time now to find out where things are with those too.

With the recent job change and the big relocation from East coast to west, I feel like I have been disconnected with the Identity community. Hopefully this IIW would get me back up to speed.