ignisvulpis

OpenID Connect Test Servers

2012-01-22T11:24:00.003+01:00

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

2011-09-26T16:23:00.000+02:00

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

2011-09-19T13:59:00.000+02:00

Ping Space

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

OpenID for Firefox Mobile Android

2011-09-14T12:42:00.000+02:00

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

2011-03-31T11:36:00.006+02:00

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

2011-03-26T00:37:00.008+01:00

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!

AES + Password Based Encryption for JSON Web Tokens

2011-03-03T15:26:00.005+01:00

I just committed some new code to the xmldap code repository. WebToken.java signs and encrypts JSON Web Tokens and WebTokenTest.java contains the JUNIT tests. These tests also show how WebToken.java is used.

Today I added Password Based Encryption (PBE) and AES encryption.

PBE uses PBEWithMD5AndDES with DESede.
AES is used in CBC mode.

PBE and RSA encryption yield in a three segment token:
jwtHeaderSegment.jwtKeySegment.jwtCryptoSegment
where
- the header segment describes the algorithm and key used,
- the key segment contains the encrypted key that is actually used to encrypt the payload
- the crypto segment contains the encrypted content.
As always each segment is base64 url encoded.

AES encryption yields in a two segment token:
jwtHeaderSegment.jwtCryptoSegment
The jwtKeySegment is not needed because AES uses a shared secret to encrypt the payload. It makes no sense to put this secret key into the token.

PBE and RSA encryption generate the encryption key and therefore this key is encrypted and send as the jwtKeySegment. JSON WebToken encryption with RSA was explained in yesterdays blog post.

Here are some example tokens (without lengthy explanation):
PBE jwtHeaderSegment: {"alg":"EPBE",
"kid":"iauxBG<9"}
PBE password: password
PBE jwtHeaderSegment base64: eyJhbGciOiJFUEJFIiwNCiAia2lkIjoiaWF1eEJHPDkifQ
PBE jwtKeySegment: {"slt":"PS023Hz4xuI","wrp":"o50kyveiYHrqg6sIPldlU4Fbi4QEnGY99FhpU_G1-zk"}
PBE jwtKeySegment base64: eyJzbHQiOiJQUzAyM0h6NHh1SSIsIndycCI6Im81MGt5dmVpWUhycWc2c0lQbGRsVTRGYmk0UUVuR1k5OUZocFVfRzEtemsifQ
PBE jwtCryptoSegment base64: CZCiieIHmirOHW17xXECoPmvIaT1de8DF5Czw0Uv1ktJ7uDAEaPj7fHM3__vnqtNLD86u2HeR7yV-UnhHn-3wF0tppv1_EJ7

fixed AES192 keybytes
[126, -34, -48, -34, 61, 72, -63, -36, 14, 53, -27, -7, -35, -57, 59, -89, 51, 84, 115, -119, -1, -125, -115, 108]
AES192 jwtCryptoSegment base64: K2xsdGRCb0tzcVdEMk1NNWdmeFlLYzdkY0V3Ry95cU5PclZZYkE0V25XMFZocW5sMVhjeDFzQWhIN2kvMVZGYms2emdHNFVrQXVSNmJjVzNaWmNBbUxtZ08xcEFybnpwYkdSWldJRlpleTRxMGI2KzVQV1hiV2JIUGh2d1kxeEM

The payload is the same as in Mike Jones' draft:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}

Enjoy.

RSA Encrypting JSON

2011-03-02T14:49:00.001+01:00

After I implemented the current draft to sign JSON: "JSON Web Token (JWT) - Claims and Signing" I implemented some simple JSON encryption.

This works by generating a ephemeral symmetric key with a specified keylength (128, 192, 256 bits) that is encrypted using the recipient's public RSA key. The ephemeral symmetric key is used to encrypt the payload using AES in CBC-mode with PKCS7 padding.
Depending on the key length the algorithms are called RE128, RE192 and RE256.

The following is an example of a JSON object that can be encoded to produce a JWT Claims Object:

{"iss":"joe",
 "exp":1300819380,
 "http://example.com/is_root":true}

The following example JSON header object declares that the encoded object is a JSON Web Token (JWT) and that the JWT Payload Segment is encrypted using the RE256 algorithm and that the RSA public key has the thumbprint of b9E8JDWjYefFiM0X9V9a098Bd6ZsFyemogCEX016uIw:

{"typ":"JWT",
 "alg":"RE256",
 "x5t":"b9E8JDWjYefFiM0X9V9a098Bd6ZsFyemogCEX016uIw"}

Base64url encoding the JSON header yields the following JWT header segment:
eyJhbGciOiJSRTI1NiIsDQogIng1dCI6ImI5RThKRFdqWWVmRmlNMFg5VjlhMDk4QmQ2WnNGeWVtb2dDRVgwMTZ1SXcifQ

The following byte array contains the UTF-8 characters for an example ephemeral key:
[27, 24, 24, 78, 51, -38, -111, -13, -53, -4, -13, -84, 34, -59, 96, 20, -23, 87, -26, -56, -116, -35, 127, -21, -97, -26, -71, 74, -36, -67, -124, -45]

The RSA key consists of a public part (n, e), and a private exponent d. The values of the RSA key used in this example, presented as the byte arrays representing big endian integers are:

Parameter Name	Value
n	[161, 248, 22, 10, 226, 227, 201, 180, 101, 206, 141, 45, 101, 98, 99, 54, 43, 146, 125, 190, 41, 225, 240, 36, 119, 252, 22, 37, 204, 144, 161, 54, 227, 139, 217, 52, 151, 197, 182, 234, 99, 221, 119, 17, 230, 124, 116, 41, 249, 86, 176, 251, 138, 143, 8, 154, 220, 75, 105, 137, 60, 193, 51, 63, 83, 237, 208, 25, 184, 119, 132, 37, 47, 236, 145, 79, 228, 133, 119, 105, 89, 75, 234, 66, 128, 211, 44, 15, 85, 191, 98, 148, 79, 19, 3, 150, 188, 110, 155, 223, 110, 189, 210, 189, 163, 103, 142, 236, 160, 198, 104, 247, 1, 179, 141, 191, 251, 56, 200, 52, 44, 226, 254, 109, 39, 250, 222, 74, 90, 72, 116, 151, 157, 212, 185, 207, 154, 222, 196, 199, 91, 5, 133, 44, 44, 15, 94, 248, 165, 193, 117, 3, 146, 249, 68, 232, 237, 100, 193, 16, 198, 182, 71, 96, 154, 164, 120, 58, 235, 156, 108, 154, 215, 85, 49, 48, 80, 99, 139, 131, 102, 92, 111, 111, 122, 130, 163, 150, 112, 42, 31, 100, 27, 130, 211, 235, 242, 57, 34, 25, 73, 31, 182, 134, 135, 44, 87, 22, 245, 10, 248, 53, 141, 154, 139, 157, 23, 195, 64, 114, 143, 127, 135, 216, 154, 24, 216, 252, 171, 103, 173, 132, 89, 12, 46, 207, 117, 147, 57, 54, 60, 7, 3, 77, 111, 96, 111, 158, 33, 224, 84, 86, 202, 229, 233, 161]
e	[1, 0, 1]
d	[18, 174, 113, 164, 105, 205, 10, 43, 195, 126, 82, 108, 69, 0, 87, 31, 29, 97, 117, 29, 100, 233, 73, 112, 123, 98, 89, 15, 157, 11, 165, 124, 150, 60, 64, 30, 63, 207, 47, 44, 211, 189, 236, 136, 229, 3, 191, 198, 67, 155, 11, 40, 200, 47, 125, 55, 151, 103, 31, 82, 19, 238, 216, 193, 90, 37, 216, 213, 206, 160, 2, 94, 227, 171, 46, 139, 127, 121, 33, 111, 198, 59, 234, 86, 39, 83, 180, 6, 68, 198, 161, 81, 39, 217, 178, 149, 69, 64, 160, 187, 225, 163, 5, 86, 152, 45, 78, 159, 222, 95, 100, 37, 241, 77, 75, 113, 52, 65, 181, 93, 199, 59, 155, 74, 237, 204, 146, 172, 227, 146, 126, 55, 245, 125, 12, 253, 94, 117, 129, 250, 81, 44, 143, 73, 97, 169, 235, 11, 128, 248, 168, 7, 70, 114, 138, 85, 255, 70, 71, 31, 52, 37, 6, 59, 157, 83, 100, 47, 94, 222, 30, 132, 214, 19, 8, 26, 250, 92, 34, 208, 81, 40, 91, 214, 59, 148, 59, 86, 93, 137, 138, 5, 104, 84, 19, 229, 60, 60, 108, 101, 37, 255, 31, 227, 78, 61, 220, 112, 240, 213, 100, 80, 253, 164, 139, 161, 46, 16, 78, 157, 235, 159, 184, 24, 129, 225, 196, 189, 242, 93, 146, 71, 244, 80, 200, 101, 146, 121, 104, 231, 115, 52, 244, 65, 79, 117, 167, 80, 225, 57, 84, 110, 58, 138, 115, 157]

The RSA public (n,e) key and the ephemeral symmetric key are then passed to the RSA OAEP encryption function.
The following byte array contains the UTF-8 characters for the encrypted ephemeral key:
[-106, 115, -121, -62, -123, 54, -119, 65, -90, 8, 65, 115, 53, 22, 74, -88, 27, 29, -120, -76, 122, -113, 69, -63, 90, -22, -29, 78, 1, 66, -59, 62]

Base64url encoding this byte array produces this value for the JWT Key Segment:
lnOHwoU2iUGmCEFzNRZKqBsdiLR6j0XBWurjTgFCxT7eSfGNpni01a3TzuaeZjVc_f3jEiuvJFYFanizkpyk9BGqCNs5LhX2m1h2Qc_llKt3TgGRi67e9p36vX81G8-QccnNQ321vutKYe2jlEvcg0hhWhejhbtK2XjsKkMaJDzEDuULbJmnAFgchSdbcYgz0JK6onX_1tO2FWed0r-EK0v9v7Y65pwz_nrYf2u8f5-j5aX2RUEYVx0sq2oaJZbbp26QmUGVPdnnEgOVI6vpL5-M6Gl1q9j645Ag94Sx9HpQcg8KEUVLfK3BfbLYGnIf-kFP8fROHuIHAMdiPD4ong

Using the symmetric key to AES256 encrypt the payload bytes and base64url-encoding the resulting bytes yields the JWT Crypto Segment:
L2ZFNFVQcCtjdWw1QTVZSGw0bUhGRDZ6NDlkNFFtRWQ1a0VBSGUzNzN3V0txY29MZmRHWkhrRUtYMUJNRWl4dzQ0RHlZcmN6TWg4WWEvN04wdUYrc01UeWlYUXBYdmV6a2JvWWd2aFQzeS9OZkpoZ2doSTN6bmViTnVwZHNZZFI

Combining these segments in the order Header.Key.Crypt with period characters between the segments yields this complete JWT using the JWT Compact Serialization (with line breaks for display purposes only):

eyJhbGciOiJSRTI1NiIsDQogIng1dCI6ImI5RThKRFdqWWVmRmlNMFg5VjlhMDk4QmQ2WnNGeWVtb2dDRVgwMTZ1SXcifQ
.
lnOHwoU2iUGmCEFzNRZKqBsdiLR6j0XBWurjTgFCxT7eSfGNpni01a3TzuaeZjVc_f3jEiuvJFYFanizkpyk9BGqCNs5LhX2m1h2Qc_llKt3TgGRi67e9p36vX81G8-QccnNQ321vutKYe2jlEvcg0hhWhejhbtK2XjsKkMaJDzEDuULbJmnAFgchSdbcYgz0JK6onX_1tO2FWed0r-EK0v9v7Y65pwz_nrYf2u8f5-j5aX2RUEYVx0sq2oaJZbbp26QmUGVPdnnEgOVI6vpL5-M6Gl1q9j645Ag94Sx9HpQcg8KEUVLfK3BfbLYGnIf-kFP8fROHuIHAMdiPD4ong
.
L2ZFNFVQcCtjdWw1QTVZSGw0bUhGRDZ6NDlkNFFtRWQ1a0VBSGUzNzN3V0txY29MZmRHWkhrRUtYMUJNRWl4dzQ0RHlZcmN6TWg4WWEvN04wdUYrc01UeWlYUXBYdmV6a2JvWWd2aFQzeS9OZkpoZ2doSTN6bmViTnVwZHNZZFI

Decoding the JWT from this example requires processing the JWT Header Segment, finding the private key to decrypt the symmetric key and using that symmetric key to decrypt the encrypted payload.

openinfocard drag and drop

2010-12-27T12:13:00.006+01:00

I used the holidays to reintegrate drag and drop into openinfocard.

After installing the openinfocard Firefox addon (xmldap-0.9.9.201012271501.xpi) and surfing to a relyingparty e.g. https://xmldap.org/relyingparty/ you can now open the Firefox sidebar (using Ctrl-Alt-Shift I).
The sidebar shows the list of Information Card you have.

You can now drag one card to the form that contains the object element. The object element is not visible but the drag and drop handler is registered to the object element and the enclosing form. In the case of the xmldap relyingparty you can drag a card to the image and the drop event will bubble up to the form.

Dragging an Information Card to the main page

Selector open with dragged card selected

xmldap relyingparty with claims from dragged card

Should I auto-submit the card because the dragging expresses the user consent already?

Information Cards, WS-Trust and SAML and OAuth, oh my!

2010-11-05T02:11:00.009+01:00

While reading Pat Patterson's blog post "WS-Trust and SAML and OAuth, oh my!" I noticed that this fits into the Information Card flow.

Pat describes Ping's Salesforce mobile flow:

Mobile app accepts the username and password, and submits them to PingFederate in a WS-Trust request.
PingFederate validates the user credentials, creates a SAML assertion and submits that to Salesforce.com in an OAuth 2.0 request.
Salesforce.com validates the SAML assertion and responds to PingFederate with an OAuth access token.
PingFederate in turn replies to the Android app with a WS-Trust response containing the access token.
The Android app uses the access token to invoke the Salesforce.com REST API.

Now let's Information-Card-ify this:

The user visits the mobile version of his company's application page at Salesforce. (No extra App just HTML5 and CSS3. Which is probably easier to implement than an App for Android and Blackberry and iPhone! The web app is available anyway.)
The site offers to use Information Cards to authenticate and the user clicks the purple-i icon to do so.
This click requests the browser to follow a link with an icard-https scheme.
The browser/OS notices that this scheme is handled by Azigo's card selector for the iPhone. We, Deutsche Telekom Laboratories, have prototype selectors for iPhone and Android too.
As it happens the card store contains an Information Card issued by the company and this card is the default card for this site. The selector contacts the card issuer (PingFederate) like in the other flow using WS-Trust.
PingFederate validates the user credentials, creates a SAML assertion and submits that to Salesforce.com in an OAuth 2.0 request.
Salesforce.com validates the SAML assertion and responds to PingFederate with a session token.
PingFederate in turn replies to Azigo's selector with a WS-Trust response containing the session token.
The selector tells the browser to post the session token the Salesforce application and the user is "in session".

So, what is different for the user and his company:

No App for each mobile platform!
The user's credentials are entered at the company site (implemented by PingFederate)!
If the card were backed by a self-issued card or by a certificate then we even get rid of username/password!

Using oauth to obtain a session token may sound unusual but then oauth is token agnostic... Or Salesforce would provide the oauth token and that would then be used by the webapp to authenticate it's calls to Salesforce's REST API... Life's good.

Thoughts?

Learn more about Information Cards at the Information Card Foundation!

blogger.com refuses to obey to HTTPS Everywhere

2010-11-05T01:54:00.000+01:00

While starting to write a new blog post here at blogger.com I noticed that the site does not use SSL. As I have HTTPS Everywhere installed I added *.blogger.com and *.blogspot.com to the list of domains were I want to use SSL the whole time.
But... my browser is always redirected to http://www.blogger.com/.
This is not what I want...

Information Cards in JSON

2010-07-01T16:28:00.006+02:00

I added some code to xmldap to serialize Information Cards to JSON.
The rationale is that XML and especially XML Signature are a mess on mobile devices. J2ME is java1.3 and thus from the stoneage. But Android (java 6) is not better because javax.xml.transform is missing. Arghh!

- I am throwing away namespaces
- No deaply nested XML structures.
- No signature (yet?)!

I would like to standardize this or something similar.

This is a Britisch Columbia Card from the RSA interop in JSON:


{
  "CardId": "urn:GUID:6d6693c1-6b1a-df11-b009-00143851d232",
  "IssuerName": "stsip.systestv2.bceid.ca",
  "MimeType": "image/jpeg",
  "lang": "en-us",
  "TokenServiceList": [
    {
      "UserCredential": {
        "Type": "UserNamePasswordAuthenticate",
        "Username": "SBCEID\\pwiebe10i"
      },
      "Address": "https://stsip.systestv2.bceid.ca/adfs/services/trust/mex"
    },
    {
      "UserCredential": {
        "Type": "UserNamePasswordAuthenticate",
        "Username": "SBCEID\\pwiebe10i"
      },
      "Address": "https://stsip.systestv2.bceid.ca/adfs/services/trust/mex"
    }
  ],
  "SupportedTokenTypeList": ["http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"],
  "Issuer": "http://stsip.systestv2.bceid.ca/adfs/services/trust",
  "CardVersion": 4,
  "SupportedClaimTypeList": [
    {
      "Description": "Level of Assurance achieved according to the rules of the ICAM IMI 1.0 profile located at http://www.idmanagement.gov/",
      "Uri": "http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel1",
      "DisplayTag": "ICAM Assurance Level 1"
    },
    {
      "Uri": "http://www.cio.gov.bc.ca/standards/claims/2009/11/useridentifier",
      "DisplayTag": "User Identifier"
    },
    {
      "Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/06/userdisplayname",
      "DisplayTag": "User Display Name"
    },
    {
      "Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/identityassurancelevel",
      "DisplayTag": "Identity Assurance Level"
    },
    {
      "Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/authoritativepartyidentifier",
      "DisplayTag": "AP Identifier"
    },
    {
      "Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/authoritativepartyname",
      "DisplayTag": "AP Name"
    },
    {
      "Uri": "http://www.cio.gov.bc.ca/standards/claims/2009/09/identityassurancelevel1",
      "DisplayTag": "Identity Assurance Level 1"
    },
    {
      "Description": "The e-mail address of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
      "DisplayTag": "E-Mail Address"
    },
    {
      "Description": "The given name of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
      "DisplayTag": "Given Name"
    },
    {
      "Description": "The unique name of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
      "DisplayTag": "Name"
    },
    {
      "Description": "The user principal name (UPN) of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
      "DisplayTag": "UPN"
    },
    {
      "Description": "The surname of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
      "DisplayTag": "Surname"
    },
    {
      "Description": "The private identifier of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier",
      "DisplayTag": "PPID"
    },
    {
      "Description": "The SAML name identifier of the user",
      "Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
      "DisplayTag": "Name ID"
    },
    {
      "Description": "Used to display the time and date that the user was authenticated",
      "Uri": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant",
      "DisplayTag": "Authentication time stamp"
    },
    {
      "Description": "The method used to authenticate the user",
      "Uri": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
      "DisplayTag": "Authentication method"
    }
  ],
  "CardName": "BCeID Information Card",
  "TimeIssued": "2010-04-15T17:52:07.341Z",
  "RequireAppliesTo": false,
  "CardType": "urn:GUID:6d6693c1-6b1a-df11-b009-00143851d232",
  "CardImage": "/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABQAHgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD340ZNBrg/FXxAGi301lbwGR4xhmCbhn9Py9qyrVoUo80jCviKdCPNUZr6l470TSbyO3u7pU3MFLZ+7k8Ej05/LtXS5NfJevXkuu+IYYVLLNczqiBjlRuIA+vNfV0TCOOOKSRTKFAPbJx6V6eNo0aMKc6cr8yv+VgoVXVTfQmzzS00dadXCbhRRRQAUUUUAFFFFABRRRQAUUUUAIa8M+KETWfiK6dJAY5grt3KsVHavUPGt5qNpoyf2asxkklCO0Kksq4PTHI7c15Le6ZqF4GMunXjseu6Fjn615ePqybVJU2+t+x4ebVZyaoxpuWzvY4a9037T5FyksiyqAYmVsFT1GD14Ne0atf3cNtAoupWEYWNsvlnKjBJPUnIJz6159ZeBL3U9UWNoZtPjQeYZ5YyNuCMbR3OSK7PUtGkWKNGv5ZCjeY5cAGRvUgdMnsK4uIs0hiaVCglyOG617K35M+m4YgneVSLW1rnqWmztc6ZaTuctJErMfUkc1brmvB+sRX1gLHyWims0VSC24MPUH+ldLXt4erGrSjOLumZ4ilKlVlCSsFFFFbGIUUUUAFFFFABRRRQAUUUUAIaMGlooAq3lhbX8apdRCRVOQCSMH8Konwvox62EZ/4E3+NTeIbuaw8NareW7BZ7ezlljYjOGVCQcH3Fckb3xJD4Eh8SQ6yJ5ltRdS29xbx+WwxkgFQCOPc0KipatIOdx2OxsNHsNMd3s7WOFnGGK55FXq5mbxlaWfgm38R3cbIs0SssCn5mdhwo/H9OaksbLXtStkutT1J7F5BuFpZon7oHszsCSfXGBTUOVdhOV2dFRXO2tvruneI4YpdQkv9JnifJliUPDIMEZZQMgjNblzdQ2kXmTyBF6c9z7UpNRV2xq7JqKy21RLiYWQFxazTITHIVXI9wDn9RXO+DtR1nVNc1uG/1RpYNNujBHGsMa+YPm5Yhc+nTFKnKNRNxewSTi0mdtRXBrea9cfEW60D+3JIrOO0F0rJbRb+SBtyVIxyea1NUj8T6Rave2F/HqixDc9rcwqjuo67WQAZ+orTk1tcnmOoorJ8N+ILTxNo0WpWmVVsq8bdY3HVTWtUtNOzKTuFFFFIAooooAxPGL+X4K1w4zmxmH5oR/WuQt/Dmr6x8OdNjttZYobSN/sckSiOUAZCFlw2O3Wu18S6dc6v4cv9OtHiSa5iMQaXO0A8Hp7ZrH0nSvFGm+HYNIE+lqYYvKW6BdmA6A7MAEj61rCVo/MiSuzgte8QLrnhPwvqL2q21raamsN1Cg+RCoGMe23P8q9pBBAIOQa5uy8EaVbeEW8OzK09vJlpZG4ZnPO/2PTH0pmlaf4k0G3SxSa01SziG2F53aGZV7AkBg2PXinNxkrLoKKa3OnZgqkngCuXtGutY1GW+SONo4iUh8xvlT3wOpqePTdZ1DWYrzVJbaG0gRxFaWzM5LsNu5mIGcAnAA707TtM1XTlkt4prfyWbIdgSw/CvMxcJOcFq49bdzqoySjJ9S/aaUIrs3lxKZ7kjAYjAUegFct4B/5GHxh/2Ej/AFrshHNBZlIWE0wBKmZiAze5AOB9BXMeFvD2taJrGq3V3JYSw6lcGdxE7hozzwMrz1HpXZQhGFNpaXMZtykmVLT/AJLVf/8AYJX/ANDWu5JAUk8Ada4dvDviaPxvJ4kgfS/ngFu1s0kmCnB+9t65HpWvf2Gv6zbNZz3Fpp1tKNsrWrNLKynqAzBQufXBraVnbUhXVznPhKh+x67PGCLSXUHMPoQPT9K9FqnpemWmjabDYWMQit4Vwqj+Z9SauVE5c0myoqysFFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD//Z"
}

Minor nit: lang="en-us". Might be better to use "en-ca"?

URL as ID

2010-06-09T10:20:00.004+02:00

HTML5 vs Flash

2010-06-09T09:43:00.003+02:00

http://www.youtube.com/html5
http://nightly.mozilla.org/webm/

Application Secrets vs. Key Pairs

2010-05-20T03:04:00.002+02:00

I was just reading about the new Google Storage API for US developers and I am wondering why we see application secrets so often?

Google is generating an application-id / "access key" and up to five application secrets for different projects a developer is working on. Fine. The developer has to sign each request to the storage API.
http://code.google.com/apis/storage/docs/getting-started.html#keys

I assume that Google might even generate code snippets for a given pair of access key and application secret to sign requests to make things really easy for the developer.

Does nobody fear that Google admins might misuse the developer credentials?
Does nobody fear that Google's database of developer credentials might be breached one day?

What is so hard in using key pairs for developers? I know that some people faint when you use the three letter word "RSA" or "DSA" or whatever smells like asymmetric crypto. But if I have to sign a request anyway then where is the difference between symmetric and asymmetric? Is performance really still an issue? gmail is now SSL which is good. So here security finally won.

Generating a keypair is really simple and using it to sign bytes is as simple as using a symmetric key. Yes you have to protect the private key but not more than you have to protect the symmetric key.

It is harder to autogenerate code snippets because the generator does not know the private key or how to access it. But is this the point?

With asymmetric crypto there is no database of keys that can be stolen because the private key is not on a central system. And the developer credentials can not abused by Google operators which is good for audits and Google's liability.

So why are symmetric keys so ubiquitous? They are nothing than passwords and share some of the problems passwords have.

oauth 2.0 scope is the new black

2010-05-18T15:42:00.006+02:00

David's openid connect proposal uses oauth2.0 to get an access token to access the user's info API.
Openid connect does not define a new flow for oauth but uses a scope with value "openid" to signify that this kind of access token is requested.

What I am missing here is that there is no way for the client to specify which of the user's information it wants to access. The users might choose to release only a subset of their information at oauth-approval-time but they have no way to know what the client is requesting. I fear that the authorization server suggests to give away all user data and that the user will grant that access.

A quote from the openid connect proposal: "The (user info) server is free to add additional data to this response (such as Portable Contacts) so long as they do not change the reserved OpenID Connect keys."

This is the Facebook notion of privacy to give everything away by default.
I don't like that.

Even if the client does not want the data it now has access to it.

I am intentionally not suggesting a different proposal or new values for scope. But what I am thinking about here is probably obvious given the background I am coming from.

XAuth is Evil

2010-04-19T11:36:00.006+02:00

Google and Meebo got it so wrong! Meebo with support by Google published a javascript xauth.js that tells a website which social networks the user is a member of. Information is stored on xauth.org and in local storage what my social networks are.

This is so wrong that it hurts. Sites should publish which social networks they support and the user should then choose which ONE they would like to use at THIS site at THIS time.
The xauth scheme just transports too much data to a central site too often.

Google should use its money and power to put this ability into the browser!
Start with Chrome and Mozilla (https://mozillalabs.com/conceptseries/identity/social-agent/). Yes, Google already supports Mozilla in this project but xauth is evil.

XAuth is not even acceptable as an intermediate "solution" before Identity in the browser is ready. Wrong, wrong, wrong.

I admit that website operators prefer it this way round and the collected data at the central server is definitely interesting and valuable. I think Google with good reason does not store that data on a Google server or do they? Who has access to that data? XAuth is not as bad as Microsoft Passport but not much better.
I fear that the user and privacy advocates are not strong enough to create "Identity in the browser"...

Don't do evil.

SHA256 et al in openinfocard

2010-04-15T23:09:00.004+02:00

I just added support for RSA-SHA256 etc to openinfocard's signature validation.
This came up during the RSA conference' OASIS IMI interop. The cards issued by ADFS2 are signed using RSA-SHA256. The team from the Government of British Columbia suggested to configure ADFS2 to use SHA1 for card signing but this way is better. Openinfocard is now more flexible in regard to signing algorithms. I added all DSA and RSA algorithms from http://www.w3.org/TR/2010/WD-xmlsec-algorithms-20100316/

Enjoy.

Comments-Policy

2010-04-10T07:34:00.003+02:00

I will delete comments to blog posts on this blog written in a language that I can not read or understand.
I disabled comments on the last blog post because it seems to draw unwanted attraction.

Identitymanagement and Sex

2010-03-18T11:13:00.007+01:00

I learned something this morning. There is an ISO norm (ISO-5218:2004) that defines the representation of human sexes in IT systems "Codes for the
representation of human sexes". Probably there is an ISO norm for everything?

The actual representation looks similar to what is defined in the OASIS Identity Metasystem Interoperability standard.

0 - Not known
1 - Male
2 - Female
9 - Not applicable

IMI does not reference ISO-5218:2004 and "0 - Not known" is something different than "0 - unspecific". I guess the authors of the IMI spec do not know the ISO norm. Or is this due to the English differentiation of "sex" and "gender"? The ISO norm defines "sexes" and the IMI standard defines "Gender".
Interesting is the sheer number of "standards" to represent gender/sex.
http://de.wikipedia.org/wiki/Datenstandards_zur_Beschreibung_des_Geschlechts
(I have not found this in the English version of Wikipedia; Sorry.)
I find it interesting too that "transgender male" and "transgender female" do not exist in many standards. Although it may be inappropriate or even illegal to store the transgender information in a database but this is not the issue. Somebody might want to prove that he was formerly a she. It is better to have a representation in a norm/standard for all cases. The legal issues are outside the standard. ("legal" is always a path to headache for me e.g. http://de.wikipedia.org/wiki/Transsexuellengesetz)
OASIS should always check that new OASIS standards might be aligned to older existing standards.
I think the "gender" section of the IMI standard should be revised.

Firefox Personas and openinfocard

2010-02-25T13:52:00.004+01:00

If you have personalized your Firefox with Personas then your openinfocard selector window now shows the same background image.

Which is nice and a security feature too. A malicious website could try to create a window that looks like your favorite openinfocard selector but the website does not know how you personalized your browser. So if your card selector window does not show the same background image as your browser then something is phishy!

Get the current (xmldap-0.9.9.201002251149.xpi) version of openinfocard now!

Did I say that openinfocard runs on MacOS Snowleopard too?

Openinfocard openid login @ plaxo

2010-02-23T17:40:00.008+01:00

When I referred to Mike's post about the Microsoft OpenID selector I was reminded to try this at the same site (Plaxo) as Mike. Here we go...

First I identified a small issue with openinfocard: The code matches the issuers now case-insensitive. Plaxo asks for "Yahoo.com" while my card says "me.yahoo.com".
So you need the latest version of openinfocard to try this "at home".
http://openinfocard.googlecode.com/files/xmldap-0.9.9.201002231732.xpi

Please install this into Firefox3 and browse to https://www.plaxo.com/signin?test.selector=1

Now click the "Sign in with OpenID" link to start the selector.

After selecting a card click "Send" to start openid discovery.

Yahoo! login and confirmation

Now I am logged in at Plaxo!

Nice!

openinfocard OpenID Selector

2010-02-23T15:19:00.010+01:00

Last autumn Microsoft demoed an OpenID selector at the OpenID summit hosted by Yahoo.
Now - finally - I found some time to add this to openinfocard.

If you have Firefox3 and Java6u12 installed then you have everything you need for this. On a Mac you need Snow Leopard to have java6. Thanks to JohnB and Pam for trying openinfocard on a Mac.

Now install the openinfocard addon into Firefox by e.g. clicking on http://openinfocard.googlecode.com/files/xmldap-0.9.9.201002121109.xpi.

Browse to https://test-id.org/XP/Selector.aspx

Clicking the button starts the Selector.

My Yahoo openid card is shown on a green background because I have visited the openid consumer (test-id.org) before and I have used this card there before.
Clicking the card image selects the card.

and you can now press "Send" to start the openid dance.
Discovery and Check Immediate are performed:

A "setup needed" is received and the Selector closes and we continue in the main browser window.

The final window: "You passed the test".

interop.ca.com for RSA 2010

2010-01-26T08:41:00.002+01:00

A quick visit of the openinfocard card selector to CA's interop site for RSA 2010.

Hm, clicking the purple-i does ... nothing; but clicking the link next to it does the job.

Now clicking the purple-i - either on the page or on the URL-bar or on the status-bar - starts the selector.

Please note the card with the name "sechs" has a green background because I used it at this site before. Noteworthy too: The selector shows Verisign's issuer logo of CA's SSL certificate.

Please update your openinfocard selector to the latest version before trying this interop.

Microsoft Update Certificate Woes

2010-01-11T09:47:00.003+01:00

When I choose "Start -> Microsoft Update" on my Windows system IE starts and shows http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de .
Security paranoid as I am I have HTTPS://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de in my list of "trusted" sites but not the HTTP-site. I am willing to pay the price to have to add the "s" after "http" every time. No problem.

What annoys me is that since some time ago the certificate is issued to "www.update.microsoft.com" but not for "update.microsoft.com".
I admit that maybe I am not supposed to visit this site because I edited the URL by hand but come on Microsoft: Please buy another certificate or configure the server to redirect me to the one and only with the correct certificate. (This prepending "www" to every webserver is stupid anyway. Leave that to the companies that are 90% marketing and 10% feature)

All OS-updates should be over HTTPS anyway. CPUs are cheap! Buy some more if the encryption is a performance issue. I want that extra SSL security.