See INTRODUCING INFOCARD, which Kim Cameron describes as "An excellent introduction to InfoCard technology by David Chappell".
The technical description of the Information Card profiles is currently controlled by Microsoft, and can be found here.
Broadly speaking, there are two kinds of cards: managed and unmanaged. Managed cards represent an identity that is mediated by an IdP, and involves authentication to that IdP. Unmanaged cards represent an identity that is mediated locally by the client and is self-asserted, but the process involves a signature using locally controlled private keys, making it somewhat ssh-like.
This support will be based on the Identity Selector Interoperability Profile V1.5 (August, 2008). If interoperability requires additional profiling, that work will be submitted to an appropriate OASIS TC.
There are no immediate plans to natively support authentication to the IdP using the Information Card profile. However, deployers can wrap the Shibboleth SP around the IdP's REMOTE_USER login handler, turning the IdP into a gateway between the Information Card and SAML protocols.
The Shibboleth 2.2 IdP may provide support for SP-NEGO authentication. This may allow the Information Card support to be subsequently extended to allow for authentication to the IdP via Kerberos. The technical details are different, but some of the back-end requirements will be similar.
There was some discussion about the need to support more than just web-based use of the profile; it was noted that Bandit has begun to think about this use case. The browser version of the profile has been engineered and profiled by Microsoft to literally disallow proof keys. Some people feel that the security benefits of tokens with proof keys (non-bearer tokens) should be available to applications that want to take advantage of them.
We agreed to think about including support for proof keys (via the symmetric and asymmetric bindings) in possible future versions of the Information Card support. Additionally, IdP support for holder-of-key models likely supplies code that may be useful to other SAML and non-SAML profiles.
Supporting authentication with unmanaged cards includes more than deploying an SP to handle the authentication itself; as an "application", the IdP is also required to support registration of a user's PPID claim and key against their authenticated identity, and then mapping to that identity at runtime. We agreed that it would be sufficient to provide a working example (e.g. using JDBC).
There are some major differences between the models that Shibboleth versions through v2.1 and Infocard use to manage the release of attributes to Relying Parties. Shibboleth imagines that a site administrator creates Attribute Filter Policies that govern the release of attributes and specific values to various SPs. Some Shibboleth extensions provide additional control models, but the basic model is that the site manages a set of policies. Infocard, on the other hand, imagines that the browser user trusts the RP based on its certificate, and wants certain attributes delivered to the RP. The common use case is the consumer case, where the IdP has essentially no organizational policy but is just serving the user's interests.
While there is relatively little in the basic Infocard profile suggesting who is supposed to trust whom for what purpose, the profile is definitely written to strongly communicate a model in which the IdP is not a vehicle for controlling what the user does or where they do it. We may run into limitations or impedance mismatches in developing a hybrid model in which both the organization and the user mutually control the release policy, or limit card use at the IdP with particular RPs.
Infocard expects a user to have a few cards, from different issuers. We're thinking about a model where a user might have a few cards from the same issuer (the different cards would release different attributes). Because of the way the claims model works, it is likely going to be impractical to pursue the multiple card model as a way to control release from the user's end unless the set of claims involved is distinct. As an example, it's certainly usable if all the cards were distinct in terms of claims and only a single card lit up for an SP. That's exactly how it should work. But, a site could certainly configure their IdP to issue a set of cards that cause significant user confusion.
Shibboleth attribute policy is designed to allow the filtering of specific attribute values. InfoCard doesn't provide for such filtering. A card might support "eduPersonEntitlement" -- in this case, policy-based filtering would still have to be done by the IdP administrator. Supporting user control over the release of individual values will be very difficult if not impossible.
It was agreed that the Shibboleth project would pursue a "hybrid" model in which the filtering engine remains involved in the attribute release process. The filtering engine does know the protocol that's being used (enabling different default release policies for different protocols -- if SAML, release nothing, if Infocard, allow the user to drive the decision).
Infocard doesn't have metadata in the same sense that SAML uses it; the client is assumed to be the agent that trusts the RP. The client usually just tells the IdP where the data will be sent, to enable bearer restrictions in the assertion and questionable methods for obtaining an encryption key.
That makes it difficult for a Shibboleth IdP to enforce policy based on RP identity without being able to reverse map from the location to the RP. This is exactly what Shibboleth got wrong in the pre-1.2 days. Unfortunately, we are now back to that situation. It is our sense that we need to extend the IdP's MetadataProvider interface, to allow lookup by endpoint.
Bandit Project's DigitalMe (Info Cards for Firefox)
Info Card Support within the Shibboleth 2.0 IdP
Info Card Support within the Shibboleth 2.0 SP