Tuesday, June 09, 2009

An feature of my G1 that I somehow did not notice until yesterday is a build-in voice search. Please notice the microfone icon next to the Google input box:If I touch that icon I can speak a search term into the G1's microfon:The recorded sound is then send to a Google server, I guess.And the result presented to me. The next image shows the result after I tried to search for "Deutsche Telekom"... Hm! (This is not faked by me)Other things work better:

Has somebody implemented speaker verification for the G1? This would be soo natural to use the mobile's microfon to verify the user!

Friday, June 05, 2009

Deutsche Telekom launched its developer program called developer garden which offers several telecom services by providing APIs.

One of these services is an IP location service that allows to resolve an IP address, if it comes from Deutsche Telekom's access network, to location information. While the retrievable location information is quite coarse it is still useful. My favorite use case is to restrict online banking to the country I live in or to the region or city I live in. This restriction would make online banking a little bit safer, although I know this is no silver bullet.Anyway, it is a good thing that the location information is not too accurate. I don't want any server to locate me. Viewed from the privacy angle even country or region/city information might be too much already.What I would like is user-centric location information. The Internet Service Provider should allow me - the user - to retrieve my location information to the accuracy that I accept. I can then hand this information over to the online shop, bank, news site, or whatever...

Today I have put this new IP location service and a security token server together. I wrote an iplocation_sts that offers Information Cards that contain location information. And I wrote an iplocation_rp that extracts this information from the security token. And it works! Yeah! Although I don't expect this to be the killer application which will make me rich or boost my career :-/ ... still I like it nevertheless.

How does it look?You visit the Identity Provider with your Information Card enabled browser e.g. Firefox 3 with openinfocard. You create an account and an Information Card that you download and install into your selector.Now you visit the relying party, click on the icon as directed...... and choose the installed location-card. This sends the token request to the IdP's tokenservice which retrieves the remote-address of the client (or its proxy :-(), generates the SAML assertion, ...that finally is send to the relyingparty.Now it is clear that I live in the region "Berlin" and that the country code is "de". Correct.

Currently this is all installed only on my local machine but if Chuck installs the required libs on xmldap.org then you can play with it (if the access provider your ISP uses is Deutsche Telekom).

Thursday, June 04, 2009

"This release is Windows 7 support-ready and includes support for Internet Explorer 8, Windows Server 2008 SP2, and Windows Vista SP2. New features include the G1 garbage collector, plus performance and security enhancements. Get it now!"

Java 5's end of life is only three month away. If you are still running Java 5 make sure that at least this is java5 update 19.

Tuesday, June 02, 2009

Some time ago I changed the HTML code that the xmldap.org site produces to XHTML.It seems that IE8 is not happy with it, although I tested all pages with http://validator.w3.org/Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)Sad. When I use IE8 and Cardspace to present an Information Card then IE8 offers to store a file to my local disk... When I post that file's content to the validator it verifies that this is valid XHTML 1.0 strict. And the content-type is "application/xhtml+xml". Maybe this is the problem?

Don't know whether I should care... Google does not consider IE8 to be a suitable browser (taken from here). Firefox is my browser and I assume that the others implement xhtml correctly too.Anyways, if one IE-enthusiast offers a solution that is standard conform then I am happy to improve the xmldap site.

Normally, before the selector requests a security token from the IdP's tokenservice endpoint it asks the metadata endpoint of the IdP and retrieves that metadata which tells it whether transport-security or symmetric-binding and other things are to be used in the token request.

I suggest that we define a simple-profile that basically skips the metadata retrievel step and replace it with default data.

The IdP that wants the simple-profile to be used just issues Information Cards that do not contain the metadata endpoint information.

What are the default values of the metadata that the selector assumes?:

Transport Security must be used; the IdP tokenservice uses SSL/TLS.

We might assume that the Information Card signing certificate is the same as the security tokenservice certificate; IFF the issuer does not use WS-AddressingAndIdentity to specify the STS certificate...

Maybe there are other assumptions that I just can not remember now? What are the security implications? Please help to make the Identity Metasystem as simple as possible (but not simpler).