- From: Paul Trevithick <ptrevithick@gmail.com>
- Date: Thu, 7 Oct 2010 09:17:04 -0400
- To: Harry Halpin <hhalpin@ibiblio.org>
- Cc: Kaliya <kaliya@mac.com>, Dick Hardt <dick.hardt@gmail.com>, Mischa Tuffield <mischa.tuffield@garlik.com>, "public-xg-socialweb@w3.org" <public-xg-socialweb@w3.org>
On Oct 7, 2010, at 9:02 AM, Harry Halpin wrote: > Paul, > > Here is the Infocard section - it's had some light editing to make it > shorter, so if you can make sure it's right: > InfoCard > > Infocard is a user-centered identity technology based on three > interrelated concepts: the card metaphor, active client software, and > the OASIS IMI protocol for identity authentication [INFOCARD!!]. As > such, it is a multi-layered integrated approach and infrastructure in > of itself. Active client software integrated with the local browser, > sometimes called a selector, acts as a local digital wallet for the > user. Each card in this wallet supports a set of profile attributes > called claims. Personal cards can be created directly by the user and > hold self-asserted claims and values. Managed cards, on the other > hand, are issued by identity provider websites that act as the > authority for the claims supported by that card. The interactions > between the active client and external services are defined by the > OASIS IMI standard [IMI!!]. Under IMI, an infocard-compatible relying > party website, usually via HTML extensions passively expresses its > policy: the set of claim URIs that it requires, the card issuer it > trusts, etc. When the user clicks on an HTML button, extensions with > the browser trigger the invocation of the active client which displays > a set of cards that support the claims required. If a managed card is > selected by the user, the user authenticates and the client fetches a > security token from the card issuer site using IMI protocols, and > POSTs it to the relying website where it can be validated and the > claim values extracted. The Infocard architecture provides phishing > resistance, eliminates the need for per-site passwords, provides a > familiar card/wallet metaphor, provides on-the-fly privacy > enhancements (e.g. attribute minimum disclosure and generation of > pseudonyms). Microsoft's Cardspace, is built into Vista and Windows 7. > Open source projects including Novell's Digital Me, OpenInfocard, and > Eclipse Higgins provide clients for MacOS, Linux, Window, iPhone as > well as support for popular browsers. Commercial and open source card > issuing services and relying party enabling technology is also > available from a number of providers. Fine > > While much has been achieved, You can delete "While much has been achieved," > Infocard remains a work in progress. Its > main disadvantage is the perceived complexity of interlocking > standards and technology needed to support the architecture, so > current work is on driving adoption via focus on applications in the > government sector. Infocard's relatively secure architecture and > privacy-respecting characteristics when compared with most > browser-redirect-based identity technologies are compelling this > marketplace. Insert "advantages to" before "this marketplace." > On the technology side, work is underway (e.g. within > [1]) on active clients that move a considerable distance beyond the > first generation clients that came to market in 2007-8. These new > clients, while implementing the IMI protocol will also add support for > other protocols is to make them interoperable. These Infocard-aware > clients incorporate Web services to at the least provide "card > roaming" across browsers and devices and can provide a "Personal Data > Store." New kinds of relationship cards that create continuous data > feeds vs. one-shot attribute conveyance are under development. Fine. > It is > expected is now moving into "identity in the browser" work. What is "It" here? Hmmm. How about: Work on active clients is increasingly seen as an aspect of "identity in the browser" efforts.
Received on Thursday, 7 October 2010 13:17:44 UTC