Tuesday, July 09, 2013

ACM Digital Identity Management

The call for papers to ACM Digital Identity Management is open http://cccs.ncl.ac.uk/dim2013/

"Identity at the Crossroads"

This workshop will explore crucial issues concerning interoperable identity management technologies for the information society.
Identity management has seen a series of development in the recent years. Whereas identity management and federation standards have been solidified and adopted in practice, nations world-wide are investing in electronic identity systems as strong root identities for their citizens offering a promise for strong authentication. Privacy-enhancing identity systems have reached some technical maturity and may offer user authentication with minimal disclosure. At the same time, personal identifiable information and the user's identity has become a commodity to drive the business of global corporations. Whereas such companies sought to bind the users accounts to their unique identity, there has been a reported unrest and anxiety of users because of their diminishing privacy protection.
We see identity at the crossroads. One possibility is the unique identification and strong authentication road that may offer increased trust for e-commerce and increasing cloud services. Another is the road of attribute exchange and leveraging the user's personal identifiable information that may benefit business and help users to have a consistent experience among many mobile compute platforms. Finally, there is the privacy-enhancing identity systems road that may offer additional protection for the user's civil rights. Partially these different roads seem to contradict each other. Research can offer roads less taken that overcome these seeming contradictions and come up with next generation identity solutions.

See you in Berlin in November!

Monday, June 10, 2013

HTTPS EveryWhere Kantara Initiative

I noticed that when I am logged into https://idp.kantarainitiative.org/ and I then access documents
on kantarainitiative.org there is no SSL protection. This is probably not good.

HTTPS Everywhere to the rescue!

HTTPS Everywhere Logo

I added my own rule to the HTTPS Everywhere Firefox addon. (Works in Firefox 21.0)

<ruleset name="KantaraInitiative">
 <target host="www.kantarainitiative.org" />
 <target host="kantarainitiative.org" />
 <target host="idp.kantarainitiative.org" />

 <rule from="^http://idp\.kantarainitiative\.org/" to="https://idp.kantarainitiative.org/"/>
 <rule from="^http://(www\.)?kantarainitiative\.org/" to="https://kantarainitiative.org/"/>

Put the above ruleset into the Firefox Profile folder into a file named e.g. kantarainitiative.xml.
On Windows it should be located in a folder similar to this location:
Now whenever I visit Kantara HTTPSEverywhere redirects Firefox to the SSL protected service.

Support EFF!

Thursday, May 30, 2013

Android SSO

The documentation of Android's AccountManager is infamously uninformative. AccountManager is available since API level 5 and I got the impression that Google changed it a lot. I am not sure whether it is still work-in-progress. Probably.

So how does Google do SSO for their own services? Not long ago Google introduced Google Play Services

Google Play Services contains an Authenticator that handles all Accounts for "com.google". The Google apps like GMail etc query this Authenticator for access tokens using the Authenticators getAuthToken method. The application can then use this access token to access the API of its backend server.

How can this be secure? How does the Google Play Services SDK (GoogleAuthUtil) know that GMail is a trusted app?
I am guessing here but I think that Google uses the same mechanism that Google recommends for developers. The keys used to sign an Android app are retrievable by the SDK and can be send to the backend. The backend then checks whether the keys match preconfigures keys.
Of course this security has its limits. On a rooted phone or a custom build phone any app can claim to be the e.g. GMail app by replacing the Android library calls that fetch the signing keys. But then Google knows to which user (Google account) a phone is registered to. Maybe this can be used to inform the user that something is going on or the account can be inactivated. Difficult.
(The new Google Play Developer Console helps.)

I think this level of security is acceptable for most consumer cases.

So let's say your company is a mobile games company (Acme Games) and you want SSO between your apps. Now write your own authenticator and put it into an apk e.g. "Acme Services".
Now each of your games can query the existence of the Authenticator for your domain "com.acme".
If it exists then ask for an access token. If it does not exist then the user has to prove to your backend that he knows something only he can know. (Successful login to a third party (e.g. Google+ Sign-In) or plain username and password). In this step you should recommend to install Acme Services because it helps the user to login to future games he will install. (And synchronization services, backup etc).

It is a pity that not each game can contain an Authenticator. In fact it can but I have not tried it out. I do not know what happens if there are several Authenticators claiming to be authoritative for "acme.com". I guess this leads to trouble or else Google would chosen this way for their own apps.
At least it takes up space in each of your app... That is the official reason given by Google:

You're done! The system now recognizes your account type, right alongside all the big name account types like "Google" and "Corporate." You can use the Accounts & Sync Settings page to add an account, and apps that ask for accounts of your custom type will be able to enumerate and authenticate just as they would with any other account type.
Of course, all of this assumes that your account service is actually installed on the device. If only one app will ever access the service, then this isn't a big deal—just bundle the service in the app. But if you want your account service to be used by more than one app, things get trickier. You don't want to bundle the service with all of your apps and have multiple copies of it taking up space on your user's device.
One solution is to place the service in one small, special-purpose APK. When an app wishes to use your custom account type, it can check the device to see if your custom account service is available. If not, it can direct the user to Google Play to download the service. This may seem like a great deal of trouble at first, but compared with the alternative of re-entering credentials for every app that uses your custom account, it's refreshingly easy.

It is a pity that GoogleAuthUtils are not configurable with your domain, your token endpoint etc. Maybe that is asking too much. We are on our own here and have to reimplements GoogleAuthUtils for our purposes.

Through the method described in this post you are creating your own identity silo. Which is OK if your company is big enough and you do not care about the access tokens being useful at other  (your business partners) sites. If you implement your own authenticator then the backend API and token format are all your own responsibility. PROTIP: use OpenID Connect.

OpenID Connect is a profile of OAuth2. Google is recommending it too. Use it!

If you want interoperability later (business partner integration) then being standard compliant make things A LOT easier!

Tuesday, May 28, 2013

Google: Standardizing Payments on the Web: Introducing requestAutocomplete()

Google is taking huge steps to simplify payments. Which is great!

If you have about 25 minutes then watch this presentation.

The major takeaways:

  • Sites should use standardized names for form input field's autocomplete attributes.
    <input id="nme" name="username" autocomplete="full-name">
    id and name stay as they are but site owner should use standard values for autocomplete.
  • The browser presents the user with a dialog that allows to choose between different sets of data; e.g. change to different shipping address.
  • On Chrome there is tight integration with Google Wallet and instead of your real credit card information a one time credit card is issued by the Google Wallet backend.
    Caveat: Google Wallet currently is US only!

Google Wallet is only one data source for autocomplete. If Google Wallet is not available then Chrome's local autofill  data is used for autocomplete.

Google said that they talked to other browser vendors but that they could not talks about it right now... Mozilla's Ben Adida compares it to the geoLocation API. Although there is not official statement from Mozilla. Apple shows no reaction yet.

Here is  a screenshot from the presentation showing sample HTML markup.

The documentation is here.

Well, this reminds me of our information card efforts.

Microsoft - the inventor of information cards - took another approach then to integrate into the website. HTML5 was not really there in 2005. Microsoft suggested to use HTML object tags and the website could use the object's parameters to specify what attribute is needed. The Information Card foundation standardized the attribute names.
We did some things differently than Google is doing now and maybe Information Cards where too secure and required too much change on the website. The most important difference between requestAutocomplete and the integration with Information Cards is that the data delivered to the site was a signed SAML token which could contain many more attributes about the user instead of only payment detail.
Providing signed data is kind of a good thing because the site - the relying party - could immediately validate the signature and be sure that the attribute values are issued by a probably trusted issuer. (I won't go into self-issued cards here)
Anyway, it seems the changes needed to be made to the site seemed to have been too big.

Google's requestAutocomplete takes a smaller step. The user experience is probably similar if you compared requestAutocomplete and the information card selection. requestAutocomplete is a big step forward for the current web if it succeeds.
The security improvements are not so big compared to information cards. The one time credit card feature is bound to Google Wallet and other browser vendors might not support Google Wallet. But this is probably not a show stopper. The security level of many current online payment schemes is in fact near zero. And requestAutocomplete is not going to change that.

One thing that I would like to build. Support for requestAutocomplete through a wallet installed on the mobile phone.

So Google's step forward is not as ambitious as the Information Card's one. But...
Who cares if the overall completion rate sky rockets.

Monday, May 27, 2013

Google Wallet Objects

During Google I/O there were several presentations about Google Wallet Objects.

Although the documentation is not public one can get a few ideas what those objects are.

What I find interesting is that we at T-Labs named the "things" inside our wallet "objects" too.

Well, at first we just called them "cards" and the wallet is a card selector. The cards can be anything: payment cards, train tickets, loyalty cards, car keys, coupons. Everything that is in your wallet.

Others called the "things" in the wallet "service". Some defined them just to be links to app on the same device as the wallet. Some defined them as meta data, that describes the service, the issuer, the service endpoints, the protocols needed to get tokens from the endpoints and so forth. Some objects contain code that is executed by the wallet.

Our T-Labs wallet objects are currently called "items" and they are all of the above.
They represent all the items in your wallet. It does not matter whether we call them items or objects.
It does not matter (much) what the import format is: XML or JSON? Currently we are using an extended OASIS IMI format. In the extensions you can specify things like "app" for a wallet external  application that provides extra functions of an item. Or you can specify "AID" to tell the wallet which cardlet on the SIM the item uses/needs.

What is important in Google's presentations is the ecosystem they are building around the wallet. Urban Airship, a Google Wallet Sandbox partner, has build a tool that makes it easy for wallet partners to create "objects". This is exactly what T-Labs demoed at the Cebit 2012 computer fair.
It has to be easy for partners to build the wallet objects/items. Most partners should not have to care about the wallet object's format. It has to be easy to create and to deploy items to the wallet.

I believe that the formats and protocols in the wallet ecosystem have to be open.
I believe that the users should control the wallet objects: what item is in the wallet.

Though I disagree with some of Google's decisions.
  • Why keep the format and protocols kind of secret? 
  • Why the restrictions? I find it laughable to try to ban "abortion". Well, maybe it is not funny.It is the user's wallet. If they want a service then the wallet should not prevent it.
    Google controls the wallet. It is Google's wallet. It is not the user's wallet. #fail
  • Why not the slightest hint to support online identity? Why not use e.g. your loyalty card or your club card to login into your favorite soccer club's fan site and online shop?
Building the whole ecosystem at once is the right way. Calling the items "objects" is a nice coincident to my work.
Interesting times...

Friday, May 24, 2013


Oh no! I should never have agreed to that IoT WebSSO  thing.

Every time I revoke that diaper token I am immediately signed back in by the craddle.

Friday, May 17, 2013

FIDO Alliance

I am not happy with the FIDO Alliance and their FAQ do not eliminate my concerns.

The major concern beeing: "Why isn't this going straight to a standards body?"
Their answer:

The FIDO authentication protocol needs to be part of a standardized, interoperable ecosystem to be successful. Building this ecosystem requires the active commitment of everybody from hardware chipset vendors, to the manufacturers of back-end server systems. Coordination across the divergent interests of these players is a complex affair, and one that current technical standards bodies are not well suited to handle.
The FIDO Alliance will refine the protocol, and monitor the extensions required to meet market needs and to make the protocol robust and mature. Implementation will not be undertaken by the FIDO Alliance. The mature protocol will be presented to the IETF, W3C or similar body after which it will be open to all industry players to implement.
This is what standardization bodies working groups are for. Work on protocols and formats. Work on security considerations. Use the experience of "the community".

So FIDO is developing a protocol and will then present it to one standardization body...
Meanwhile it is a closed thing and it costs relevant amounts of money to join the alliance.
This neither free nor open.

During IIW there were several sessions on FIDO (1, 2). Each full of good intentions and marketing speek but no substance. No real information. You have to join the alliance to get that. Well, ...

Somebody at Nok Nok Labs convinced somebody at Paypal to hire them and found FIDO. Why Google joined despite Google's support for the W3C WebCrypto group I have no idea.

The W3C WebCrypto group is were this belongs. This might need rechartering of the group. But that is doable. Especially if the proposal is backed by a prototype implementation. Especially if it is backed by by Paypal, Lenovo, Google, Nxp and others.

I believe that we need better authentication methods beyond username and password. I think that bring your own (hardware) identiy might work to that goal. I believe that mobile phones, and SIM cards and NFC help to achieve this. I believe that the mobile wallet is the right user interface to choose your identity.

I believe that doing it in a closed group is not the right way.