Thursday, May 30, 2013

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!

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.WhatWG

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.

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

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 17, 2013

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.