Web Identity Restart?

Well, how can you restart something that never started? ... Never mind.

I am wondering whether it makes sense to have a W3C workshop on "Internet Identity" again. http://www.w3.org/2011/identity-ws/

My impression in 2011 was that the common ground was not very broad so the group decided to launch the W3C WebCrypto working group because all agreed that crypto is a precondition to web identity. Now, three years later I do not see much progress in web crypto or web identity (for that matter).

In the meantime the FIDO alliance was established which has HW-based authentication but a license model that requires that implementers are a FIDO alliance member. That is the opposite of a web standard.

So I think that the WebCrypto WG will not give us "identity for the web". Signing/verification/encryption/decryption are too low level and too easy to use wrong. This is not the way to web identity.

Maybe it is time to restart the web identity effort in W3C.

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!

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!

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/"/>
</ruleset>

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:

D:\Users\nennker.axel\AppData\Roaming\Mozilla\Firefox\Profiles\uzmmhdde.default\HTTPSEverywhereUserRules

Now whenever I visit Kantara HTTPSEverywhere redirects Firefox to the SSL protected service.

Support EFF!

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!

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

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.

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

ALERT - DIAPER DANGEROUSLY FULL

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.

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.

Javascript API for OpenID

Too long ago I wrote about an Javascript API for openid: all those NASCARs

To repeat the main points:

Sites currently have no easy way to detect support for openid
The site can detect support for openid like so:

   if (window.openid) { don't show the nascar }

The DOM level API that allows the site to query the preferred identity provider looks like this:

   window.openid.getPreferredOpenidProvider(callback);

In a world of oauth2 and openid connect this could be generalized to:
https://openid.net/specs/openid-connect-standard-1_0.html#rf_prep

    var parameters = {};
    parameters.response_type="id_token";
    parameters.client_id="https://server.example.com/seminar/callback.html";
    parameters.request = "eyJhbGciOiJSUzI1NiIsIng1dSI6Imh0dHBzOlwvXC9nYWJ1bm9taS5uZXRcL3NlbWluYXJcL3JzYV9wdWJsaWNfa2V5LnBlbSJ9.ewoJInJlc3BvbnNlX3R5cGUiOiAiaWRfdG9rZW4iLAoJInNjb3BlIjogIm9wZW5pZCIsCgkiY2xpZW50X2lkIjogImh0dHBzOi8vZ2FidW5vbWkubmV0L3NlbWluYXIvY2FsbGJhY2suaHRtbCIsCgkicG9saWN5X3VybCI6ICJodHRwczovL2dhYnVub21pLm5ldC9zZW1pbmFyL3BvbGljeS5odG1sIiwKCSJ1c2VyaW5mbyI6IHsKCQkiY2xhaW1zIjogewoJCQkibmFtZSI6IG51bGwsCgkJCSJlbWFpbCI6IG51bGwsCgkJCSJwaWN0dXJlIjogbnVsbAoJCX0KCX0sCgkicmVnaXN0cmF0aW9uIjogewoJCSJhcHBsaWNhdGlvbl9uYW1lIjogIlNhbXBsZSBTZW1pbmFyIiwKCQkibG9nb191cmwiOiAiaHR0cHM6Ly9nYWJ1bm9taS5uZXQvc2VtaW5hci9sb2dvLnBuZyIsCgkJIng1MDlfdXJsIjogImh0dHBzOi8vZ2FidW5vbWkubmV0L3NlbWluYXIvcnNhX3B1YmxpY19rZXkucGVtIgoJfQp9Cg.Faytuhwb2W4CWVz2-10umSieh-bqR7QXqU0bNF39u_D0mGoBD4e3X2b4jZNqPvPADSnQhlBGSJu189iFM5bwFzchnO-quCpj7T2CK_-wkrpL5LUn_WHYMmYlFadmb-a1p-TEo7exU9azMS9cT70-kHNqmTaJziZyiAMoJ0Q4TtyTt1Xbkknc_CQRug3ilNv3bEXSlOlva3HUOY7jQIbYMB3jDL3QxS1wbVYNAjOxCxCDmiNAUJA-BkYe6Tpyj-DUs57IM4wQSp64sqim8RqirJJfFb4bCbNTkC3G8sYfN2_1-qEDpOnWW7N3gjl174TWHbnzVLAZGg_rZm58-wHOLw";
    parameters.state="509b9cafd3119";
    parameters.nonce="509b9cafd34fd";

    window.openid.connect(parameters, oc_callback);

The callback

oc_callback

would be called with one parameter.

function oc_callback(resp) {
  // resp contains a signed then encrypted id_token in jw-* format
  // https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption
  // https://tools.ietf.org/html/draft-ietf-jose-json-web-signature
  // state and nonce are inside the resp parameter too
  // need a private key to decrypt it so forward it to my own validation endpoint
  $.post("validate.php", { resp: resp },
   function(id_token) {
     alert("returned id_token: " + id_token);
   }); 
}

The general idea is: put all http request parameters which are defined in openid connect into the request object. Put all the http respones parameters into the response object.

I think we need an Javascript API for identity that is supported by browsers. BrowserID/Persona and AccountChooser do something in this direction but not enough.

ECDH-ES for JSON Web Encryption

The JSON WebToken spec RECOMMENDS that ECDH-ES is implemented. Here we go:

Here are the relevant snippets from the JWA spec:


4.1. "alg" (Algorithm) Header Parameter Values for JWE

alg Parameter Value	Key Encryption or Agreement Algorithm
ECDH-ES	Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC 6090 , and using the Concat KDF, as defined in Section 5.8.1 of NIST.800-56A, where the Digest Method is SHA-256 and all OtherInfo parameters are the empty bit string

4.6. Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)

This section defines the specifics of agreeing upon a JWE CMK with Elliptic Curve Diffie-Hellman Ephemeral Static, as defined in RFC 6090, and using the Concat KDF, as defined in Section 5.8.1 of NIST.800-56A, where the Digest Method is SHA-256 and all OtherInfo parameters are the empty bit string. The alg header parameter value ECDH-ES is used in this case. A key of size 160 bits or larger MUST be used for the Elliptic Curve keys used with this algorithm. The output of the Concat KDF MUST be a key of the same length as that used by the enc algorithm. An epk (ephemeral public key) value MUST only be used for a single key agreement transaction.

Appendix B. Encryption Algorithm Identifier Cross-Reference

Algorithm	JWE	XML ENC	JCA
Elliptic Curve Diffie-Hellman Ephemeral Static	ECDH-ES	http://www.w3.org/2009/xmlenc11#ECDH-ES	TBD

I could not find a Java implementation in JavaSE and the Bouncycastle library does not seem to have one neither. Bouncycastle does implement keyderivation functions but not the one from NIST.800-56A. Valuable input came from this webpage "Key Derivation Functions: How many KDFs are there?". Taking the Bouncycasle implementation and converting it into KDFconcat is easy and here it is: https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmldap/crypto/KDFConcatGenerator.java

The next thing needed are some keypairs for the JUNIT test cases. I generated them using openssl.

openssl ecparam -out key1.pem -name secp256r1 -genkey

and displayed them using

 openssl ec -in key1.pem -text
read EC key
Private-Key: (256 bit)
priv:
    07:2f:23:22:c0:e7:5e:0c:85:17:64:b4:21:81:99:
    67:78:fd:22:59:2f:87:e5:d4:38:36:09:74:29:a1:
    c3:fc
pub:
    04:ed:3c:83:1b:f3:e1:05:9f:12:07:7f:4b:e4:fd:
    fe:90:55:73:d1:c6:76:45:b4:7d:48:64:ea:17:9d:
    de:99:86:a9:a6:ad:34:27:4a:80:fc:94:b3:a5:ef:
    6c:6e:78:2c:22:7a:39:63:a6:a4:26:50:97:6d:a6:
    ad:e9:90:a1:61
ASN1 OID: prime256v1
writing EC key
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIAcvIyLA514MhRdktCGBmWd4/SJZL4fl1Dg2CXQpocP8oAoGCCqGSM49
AwEHoUQDQgAE7TyDG/PhBZ8SB39L5P3+kFVz0cZ2RbR9SGTqF53emYappq00J0qA
/JSzpe9sbngsIno5Y6akJlCXbaat6ZChYQ==
-----END EC PRIVATE KEY-----

Too bad that the man page does not go into detail in what format priv and pub are... Read the source, Luke! It seems that the priv key D is just the bytes in hex of the private key BigInteger. The public key seems to be something else but this is no problem because in ECC the public key is G*D where G is a curve parameter.
So the two private keys are now defined here in the JUNIT tests. One is for the sender of the JWE the other for the recipient.

  static final String ec256_a_priv = "072f2322c0e75e0c851764b42181996778fd22592f87e5d43836097429a1c3fc";
  static final String ec256_b_priv = "1a3eda89dc067871530601f934c6428574f837507c578e45bd10a29b2e019bfb";

Now the public keys are computed like this:

  ASN1ObjectIdentifier oid = ECUtil.getNamedCurveOid("secp256r1");
  X9ECParameters x9ECParameters = ECUtil.getNamedCurveByOid(oid);
  byte[] ec256_a_priv_bytes = Hex.decode(ec256_a_priv);
  ec256_a_D = new BigInteger(1, ec256_a_priv_bytes);
  ECPoint pub = x9ECParameters.getG().multiply(ec256_a_D);
  ec256_a_X = pub.getX().toBigInteger();
  ec256_a_Y = pub.getY().toBigInteger();

This gives the following jwtHeader for the first private key: ECDH-ES jwtHeaderSegment:

{"alg":"ECDH-ES",
"enc":"A256GCM",
"iv":"__79_Pv6-fg",
"crv":"secp256r1",
"x":"AO08gxvz4QWfEgd_S-T9_pBVc9HGdkW0fUhk6hed3pmG",
"y":"AKmmrTQnSoD8lLOl72xueCwiejljpqQmUJdtpq3pkKFh"}

The spec says that the senders key pair is ephemeral and the recipient's key pair is static. So code using this code should generate one ephemeral EC key pair. Stuff the private key and the recipients public key into the encrypt function. These key parts are used for the key agreement. See the wikipedia page for a short explanation. I will implement the "epk" header parameter at a later time. For now I use the X and Y format to transfer the ephemeral public key to the recipient.
Base64 encoding the header yields:

eyJhbGciOiJFQ0RILUVTIiwNCiJlbmMiOiJBMjU2R0NNIiwNCiJpdiI6Il9fNzlfUHY2LWZnIiwNCiJjcnYiOiJzZWNwMjU2cjEiLA0KIngiOiJBTzA4Z3h2ejRRV2ZFZ2RfUy1UOV9wQlZjOUhHZGtXMGZVaGs2aGVkM3BtRyIsDQoieSI6IkFLbW1yVFFuU29EOGxMT2w3Mnh1ZUN3aWVqbGpwcVFtVUpkdHBxM3BrS0ZoIn0

The next step in my interpretation of the spec is to generate the content encryption key using the key derivation function defined in the NIST paper. The content encryption is done using the method specified in the enc parameter of the header here: A256GCM
For this method I need a 256bit == 32byte key and a 12 byte IV. So the call to the KDF is:

  ECDHBasicAgreement ecdhBasicAgreement = new ECDHBasicAgreement();
  ecdhBasicAgreement.init(ecPrivateKeyParameters);
  BigInteger z = ecdhBasicAgreement.calculateAgreement(ecPublicKeyParameters);
  byte[] zBytes = BigIntegers.asUnsignedByteArray(z);
  KDFConcatGenerator kdfConcatGenerator = new KDFConcatGenerator(kdfDigest);
  kdfConcatGenerator.init(new KDFParameters(zBytes, null));
  byte[] out = new byte[12 + (keylength / 8)];
  kdfConcatGenerator.generateBytes(out, 0, out.length);
  byte[] secretKeyBytes = new byte[keylength / 8];
  byte[] ivBytes = new byte[12];
  System.arraycopy(out, 0, ivBytes, 0, 12);
  System.arraycopy(out, 12, secretKeyBytes, 0, secretKeyBytes.length);

Now a random 256bit AES key is generated and encrypted using the secret key and IV generated by the KDF.
For this content encryption key (base64url)

ECDH-ES contentEncryptionKey=Y8-fcu11np1l3qlgpGq0XF58Cv2n4DOJ8lkdl2gRXgI

the values of the key segment and the jwe crypto segment are this:

ECDH-ES jwtSymmetricKeySegment base64: _vZ-N5fs3_uJ9o-woDOzKZBQopZRi4EfZVNB4UWqdCjappfoOFCZPTUBDruWAtWY
ECDH-ES jwtCryptoSegment base64: psSi2xa7oY1pmK1m9GGXREr9YB6QUdOtK_Jl_nnKYpmKGHL577tUdadK8H_yacb78bBlyTnrTx51pmxyo6UJMM9c_P-lOfMiMslvS-3t1vD5HiOq0Rg

Please use the IETF JOSE mailing list for comments and suggestions.

Special thanks to Mike Jones for writing most of the JW* specs text and to John Bradley for being a fountain of knowledge in all things crypto and identity management protocols and formats. Not to forget Nat Sakimura for starting the OpenID Artifact Binding WG which now does all the OpenID Connect work. Especially for mobile devices we need simple, light weight protocols and formats. JW* and especially ECDH-ES are important for mobile.

Playing with Google's Identity Toolkit on openinfocard.org

Today I retried Google's Identity Toolkit.
https://developers.google.com/identity-toolkit/v1/acguide
So I had to undust my rudimentary PHP knowledge and write some scripts and minimal html pages.

Clicking the key hole icon opens the account chooser.

I choose GMail and login to Google.

This is the result page. My site now knows some attributes about me like verifiedEmail, display name and imageUrl etc.

Next task: Repeat and rinse with http://accountchooser.net/

Debugging OAuth2 SSL Connections

Debugging SSL protected protocols like oauth2 can be a problem but it is not entirely impossible nor hard to do.

One way to do it is to spoof the certificates the protocol relies on to protect the communication. The certificates are used by the client to verify that the server is the endpoint it is supposed to be talking to and to encrypt the communication. A good description for the Android operating system is given in this blog post (Intercepting and decrypting SSL communications between Android phone and 3rd party server). Nobody can blame Android for being picked here as an example and ways to do this exist for all operating systems. Yes, to install the certs you need root access; but it well may be that you have that and want to help a friend to debug their installed application on your phone. Even if the client is running on a server it may be worthwhile to debug the network traffic to find certain errors in the client implementation. An error specific to an oauth implementation might be that your friend has a typo in the cliend_id or client_secret and the authorization server is rejecting requests because of that.
It might be hard for you to verify client_id and client_secret by analyzing the client. Maybe they are stored on a UICC or stored encrypted in the file system (and the keystore password is not "changeit") and are only decrypted and used when a resource owner uses the client.
By analyzing the SSL traffic you can help to find this kind of bug and all other related to protocol issues.

But maybe you don't have an SSL server to capture the plain text from an SSL connection?! Then another path you might take is to swap the client's SSL implementation with your own. You don't have to change the client's code or analyze the client's memory. Building your own version of most operating systems with your own SSL implementation is not that hard to do. Or maybe you can just register your SSL implementation to be used with all client code? Or you can swap a library?
There are more ways to achieve your goal.

But make sure that you have your friend's permission first. Not everybody might be happy with the fact that you now know the client_id and client_secret.

Have fun!

Identity Management @ RSA 2012 Europe

Sharpen your keyboard and submit a paper for the Identity Management track at RSA Conference Europe 2012. The leading conference on security and all things you need to know.

From the topic description: Identity Management
Identity Management covers issues of access control, authentication, identification technologies & protocols. Sessions on Identity and Access Management (IAM) fit here, along with sessions on IAM standards and architecture. This topic also covers issues such as credential management, multifactor authentication and new methods of authentication.

The Call for Speakers closes on Friday 18th May

Myhabit.com unconfused

Here the unconfusing part with was censored in one other post about the same UI.

Note the Amazon favicon and URL.

OpenID Connect Test Servers

Here are some experimental OpenID Connect server configurations:

https://connect-op.heroku.com/.well-known/openid-configuration

{
  "version":"3.0",
  "issuer":"https://connect-op.heroku.com",
  "authorization_endpoint":"https://connect-op.heroku.com/authorizations/new",
  "token_endpoint":"https://connect-op.heroku.com/access_tokens",
  "userinfo_endpoint":"https://connect-op.heroku.com/user_info",
  "check_id_endpoint":"https://connect-op.heroku.com/id_token",
  "registration_endpoint":"https://connect-op.heroku.com/connect/client",
  "scopes_supported":[
    "openid",
    "profile",
    "email",
    "address",
    "PPID"
  ],
  "response_types_supported":[
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "id_token token"
  ],
  "user_id_types_supported":[
    "public",
    "pairwise"
  ],
  "x509_url":"https://connect-op.heroku.com/cert.pem"
}

https://openidconnect.info/.well-known/openid-configuration

{
  "version":"3.0",
  "issuer":"https://openidconnect.info/",
  "authorization_endpoint":"https://openidconnect.info/connect/authorize",
  "token_endpoint":"https://openidconnect.info/connect/token",
  "user_info_endpoint":"https://openidconnect.info/connect/userinfo",
  "check_id_endpoint":"https://openidconnect.info/connect/check_session",
  "registration_endpoint":"https://openidconnect.info/connect/register",
  "scopes_supported":[
    "openid",
    "profile",
    "email",
    "address",
    "PPID"
  ],
  "flows_supported":[
    "code",
    "token",
    "code id_token",
    "token id_token"
  ],
  "identifiers_supported":[
    "public",
    "ppid"
  ]
}

https://connect.openid4.us/.well-known/openid-configuration

{
  "version":"3.0",
  "issuer":"https:\/\/connect.openid4.us",
  "authorization_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/auth",
  "token_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/token",
  "userinfo_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/userinfo",
  "check_id_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/check_id",
  "refresh_session_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/refreshsession",
  "end_session_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/endsession",
  "jwk_url":"https:\/\/connect.openid4.us\/connect4us.jwk",
  "jwk_encryption_url":"https:\/\/connect.openid4.us\/connect4us.jwk",
  "x509_url":"https:\/\/connect.openid4.us\/connect4us.pem",
  "x509_encryption_url":"https:\/\/connect.openid4.us\/connect4us.pem",
  "registration_endpoint":"https:\/\/connect.openid4.us\/abop\/op.php\/registration",
  "scopes_supported":[
    "openid",
    "profile",
    "email",
    "address"
  ],
  "response_types_supported":[
    "code",
    "token",
    "id_token"
  ],
  "acrs_supported":[
    "http:\/\/www.idmanagement.gov\/schema\/2009\/05\/icam\/openid-trust-level1.pdf"
  ],
  "user_id_types_supported":[
    "public",
    "pairwise"
  ],
  "userinfo_algs_supported":[
    "HS256",
    "RS256",
    "A128CBC",
    "A256CBC",
    "A128KW",
    "RSA1_5"
  ],
  "id_token_algs_supported":[
    "HS256",
    "RS256",
    "A128CBC",
    "A256CBC",
    "A128KW",
    "RSA1_5"
  ],
  "request_object_algs_supported":[
    "HS256",
    "RS256",
    "A128CBC",
    "A256CBC",
    "A128KW",
    "RSA1_5"
  ],
  "token_endpoint_auth_types_supported":[
    "client_secret_post",
    "client_secret_basic",
    "client_secret_jwt",
    "private_key_jwt"
  ],
  "token_endpoint_auth_algs_supported":[
    "HS256",
    "RS256"
  ]
}

 Happy testing!

Stackoverflow.com OpenID for Firefox Mobile Login

The version 1.2.1 of OpenID for Firefox Mobile works on more web pages .e.g. stackoverflow.com

Stackoverflow.com login

You can either use the toolbar icon to start the OpenID flow

OpenID for Firefox Mobile toolbar icon

or you can use the page action to start the OpenID flow.

OpenID for Firefox Mobile page action

Google Accounts Authorization

Stackoverflow.com account creation

n dimensional Ping Space

Ping Space

In response to http://connectid.blogspot.com/2011/09/new-line-of-greeting-cards.html

OpenID for Firefox Mobile Android

OpenID for Firefox is now available for Firefox Mobile (Fennec) on Android.


This screenshot shows the OpenID icon in the toolbar. Tapping the icon inserts the preferred OpenID into the OpenID input field.

The OpenID icon in the toolbar

Installation instructions:
Browse to Addons@Mozilla and install the version 1.2 or newer:
https://addons.mozilla.org/en-US/firefox/addon/openid-for-firefox/versions/

"OpenID for Firefox" at mozilla

Add to Firefox

  

Confirm the installation.

Add-on installation dialog

Restart the browser.

Configure Firefox Sync to sync your OpenIDs from your desktop machine to your Android device.

Browse to a site that supports OpenID. e.g.: http://wiki.idcommons.net/Special:OpenIDLogin

The mobile version of OpenID for Firefox does not have all the nice features of the desktop version. You can not (yet) choose between OpenIDs when logging in. I needed a few evenings to adjust to the differences in addon development between the desktop and mobile versions of Firefox. But now I am confident that I can implement an account chooser for OpenIds on Firefox Mobile soon.

All those NASCARs

We did not really make a breakthrough in the last years on the questions of
- Identity Provider Discovery
- security and privacy UI
- Identity in the Browser
- intelligent agents or what ever you call them
- openid UI
- add your favorite here...

Although we did not have a lack of efforts to solve some of these issues
- cardspace
- openinfocard
- azigo's selector
- Kantara login ULX
- openidsamplestore.com
- Janrain's Engage
- ...

We really need browser support. So lets start - again - with: Identity in the Browser.

Requirements:
- user centric
- ask for user consent before leaking information.
- help the users discover the reusable identities they already have.
- don't favor any identity provider.
- not to many user choices. Keep it simple.
- allow the site to detect whether or not identity in the browser is supported or not.

I created a Firefox addon that tries to achieve just that.
http://ignisvulpis.blogspot.com/2011/03/openid-for-firefox4.html
Or at least go in that direction. I concentrated on openid support but I think it is easy to generalize from there.

The DOM level API that allows the site to query the preferred identity provider looks like this:

window.openid.getPreferredOpenidProvider(callback);

The site can detect support by testing for the new child of the window object to be present:

if (window.openid) { don't show the nascar }

Maybe I should not have named this "window.openid" but "window.identity"?!
I guess that is for the W3C to decide. They just added another event to Identity-May:
"W3C Workshop on Identity in the Browser"

I really hope that we get W3C support for Identity. It is not important whether this is called window.openid or navigator.openid or whatever. We have a nice example for another W3C API: Geolocation and I modelled my Identity API suggestion along those lines.

What next?
I) The UI of my addon is not that polished.


a) In this case the file-url is especially ugly and in this case there are not that many alternatives.
In the website case the addon could
- show the site's URL
- show the site's favicon instead of URL
- show the site's icon from the extended validation certificate
- show the site's "other icon" which I don't know how to get in a standardized way
- show the site's name / title from the webpage
- show the site's name from the certificate

b) Should I show which openid the addon is going to provide to the site?
Actually the user does not really care whether this is an openid or whatever.
Here the addon could
- show the user's openid.claimed_id
- show the user's openid.identity
- show the OpenID Provider's (OP) favicon from the openid.op_endpoint
- show the user's icon/image provided by the OP
- let the user add an icon to that openid

II) Should the addon use the Firefox notification-box or the newer notification popups?
The notification box might be to easy to fake by a website but then there is no real point in faking it. Or is it?

III) Learning new OpenIDs notification popup

Here the addon could
- show the user's openid.claimed_id (as seen in the picture above)
- show the user's openid.identity
- show the OpenID Provider's (OP) favicon from the openid.op_endpoint
- show the user's icon/image provided by the OP
- let the user add an icon to that openid

IV) Does the user already have reusable Identities?
- The addon could just open a tab that shows the OpenID Foundation's "get an openid" page.
- I implemented a feature where the browser helps the users find their reusable identities. The browser knows a lot about the sites the user visited and might have stored the user's credentials for some sites. My implementation iterates through all domains with stored credentials and requests the Yadis XRD. If the XRD contains openid information then the domain is shown as an potential "openid you might already have".
This feature is not in the version I have uploaded to Mozilla.
- The addon could use Mozilla's Firefox Sync openid provider. Which would violate the rule not to prefer some identity providers...

V) Mobile support
Firefox mobile is out. The addon currently does not support Firefox mobile. Which brings me to the next point.

VI) The addon could add identities (openids) to form input fields from a context menu. Right click the page or input element and a choice is presented to the user to input the openid into that input field. But on the other hand this should be done better by the site's javascript code after it has detected support through the DOM API.

VII) Support identities issued by mobile operators.
Should be easy... Support mobile wallets.

VII) The openid icon in the url-bar might be too much for other providers. I don't care for now.

Please support Identity in the Browser!

OpenID for Firefox4

I created an addon for Firefox4 that learns your OpenIDs when you use them.

The addon then asks you whether it may store the discovered openid (claimed_id) shown here at the identity commons site:

Another thing the addon does is that it allows the site to query the DOM for your preferred openid:

This is the source code of the last page:
<html><head><title>JavaScript-Test</title>
<script type="application/javascript">
 function start() {
   try {
    window.openid.getPreferredOpenidProvider(function(preferredOpenidProvider) {
  var p = document.getElementById("id");
  p.textContent = preferredOpenidProvider;
});
   } catch(e) {alert("exception="+e);}
  }
</script>
</head><body>
<form><input type=button value="Start" onClick="start()"></form>
<p id="id">openid</p>
</body></html>

The addon then asks the user for her consent to provide the openid to the site:

Clicking the openid urlbar icon inserts the openid to an appropriate input field on the page. If the addon did not learn an OpenID in the past it opens the OpenID Foundation's "Get An OpenID" page"

Google's openidsamplestore does NOT put an id or name on the input fields making it impossible for the addon to determine the correct input field. Shame on you Google! You can drag the OpenID urlbar icon to the correct field to insert your OpenID into the field.

 

The addon works on Stackoverflow too:

Get Firefox4 now and please try out this new addon!