Twitter Markup

Twitter Cards are around for some time now and I recently wondered how commonly used they are?

There is a nice blog post on Blogger on how to integrate them there but clearly there should be ways for e.g. newspapers to promote their reports by providing summaries and a main image and author information that is not @Twitter specific?  Microformats and schema.org to the rescue?

What does Google do? It seems that JSON-LD is the recommended format.

How would a Twitter Card look in JSON-LD?

Twitter Cards or Rich Cards or @w3c Cards?

Time to standardize!

XAuth is Evil

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.

John Clippinger on i-cards and Google wave

John Clippinger, who directs the Law Lab at Harvard University and who is a co-founder of Parity Communications now Azigo, talks about Information Cards, the wallet and that this will be integrated into Google wave.

This video is from the ideas project:


My hope is that companies like Google will help to put Information Cards into the browser.

Google Voice Search on Android

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!

Your search - cardspace site:microsoft.de - did not match any documents.

http://www.google.de/search?q=cardspace+site%3Amicrosoft.de yields:

Not good! It seems that the German Microsoft site is not searched by Google. Strange.
Ahh. Searching for German language content on microsoft.com yields results...
Still...

Searching for Cardspace at search.microsoft.com results in an interesting suggestion: "Meinten Sie vielleicht: cards pace" (did you mean 'cards pace'). It seems that search.microsoft.com does not know Microsoft products.

Information Cards for Google Apps

Information Cards are an industry standard that enable people to maintain a set of personal digital identities.
Information Cards are like cards in your wallet. Each one defines a relationship between you -the cardholder- and the card issuer -the identity provider. They provide a way to transfer claims/attributes from the identity provider to a relyingparty. Information Card selectors are available for all major operating systems and major browsers. To learn more about Information Cards please visit the Information Card Foundation.

Having provided support for "SAML Single Sign-On (SSO) Service for Google Apps" not so long ago Google is now proud to present support for Information Cards for Google Apps.
The step from "SAML Single Sign-On (SSO) Service for Google Apps" to Information Card support is actually quite small. This is due to the fact that all Information Card selectors are token agnostic that is: They don't care which type of token is transfered from the identity provider to the relying party. Therefore we choose to use SAML assertions that are used in "SAML Single Sign-On (SSO) Service for Google Apps" too.

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content.

Google Apps offers an Information Card based claims transfer that provides partner companies with full control over the authorization and authentication of hosted user accounts that can access web-based applications like Gmail or Google Calendar. Using the Information Card model, Google acts as the relying party and provides services such as Gmail and Start Pages. Google partners act as identity providers and control credentials and other information (claims/attributes) used to identify, authenticate and authorize users for web applications that Google hosts. Google wants to point out that it is hard to overestimate the security gains for our partners. By using the authentication methods implemented in e.g. Windows Cardspace partners can use Kerberos, X509 and self-issued cards to authenticate the user to the security token server; thereby leveraging existing corporate infrastructure to access Google Apps through this new services.

There are a number of existing open source and commercial identity provider solutions that can help you implement Information Cards with Google Apps.
It is important to note that the SSO solution only applies to web applications. If you want to enable your users to access Google services with desktop clients such as Outlook—for example, Outlook would provide POP access to Gmail—you will still need to provide your users with usable passwords and synchronize those passwords with your internal user database using the Provisioning API.

The Google Apps with Information Card is based the "Identity Selector Interoperability Profile V1.5". Information Cards are supported by several widely known vendors. Visit the Information Card Foundation to learn more.

Understanding Information Card based usage of Google Apps

The following process explains how a user logs into a hosted Google application through a partner-operated identity provider service.

Figure 1: Logging in to Google Apps using Information Cards


This image illustrates the following steps.

1. The user attemps to reach a hosted Google application, such as Gmail, Start Pages, or another Google service.
   Google presents a page with the purple-i that denotes that Information Cards can be used here. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is transferred to the Google ACS as a form parameter. This RelayState parameter not transferred to the partner. Each google app requests at least one claim that is identitcal to the applications base url e.g. "http://calendar.parityapps.com/".
2. The user clicks the purple-i icon
3. The cardselector starts and the user selects her information card e.g. the managed card issued by Parity. The card selectore sends the security token request to the partner
4. The partner parses the request and authenticats the user using one of the supported authentication methods Kerberos, X509 certificate, self-issued card or username and password
5. Partner generates SAML assertion (security token).
6. The browser posts the security token and the other form element's values to the Google ACS
7. Google's ACS verifies the SAML response using the partner's public key. If the response is successfully verified, ACS redirects the user to the destination URL.
8. The user has been redirected to the destination URL and is logged in to Google Apps.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hope to read an anouncement like the fake one above by Google soon ;-)