Cover Pages: XML Daily Newslink: Tuesday, 04 March 2008

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com

Headlines

Eclipse Higgins Version 1.0 Supports User-Centric Identity Framework
Federated Identity Through the Eyes of the Deployer
Acid3: Putting Browser Makers on Notice, Again
Microsoft's Interoperability Principles and IE8
GridShib SAML Tools Version 0.3.0
OASIS Open Reputation Management Systems (ORMS) Technical Committee
Element Traversal Specification

Eclipse Higgins Version 1.0 Supports User-Centric Identity Framework
Staff, Eclipse Foundation Announcement

The Eclipse Foundation recently announced the availability of Eclipse Higgins 1.0, a freely downloadable identity framework designed to integrate identity, profile and social relationship information across multiple sites, applications and devices using an extensible set of components. Web 2.0, mashups, social networking and the general rise of networked applications have made Web-based identity management complex for both the end-user and the developer. The Eclipse Higgins project, a coalition of organizations and individuals, has been working to address these issues. Multiple identity protocols have been developed to address different needs, including WS-Trust, OpenID, SAML, XDI, LDAP, etc. This requires software developers to support multiple protocols, resulting in unnecessary complexity in managing identities. Additionally, individuals are particular about which entities they share what personal information. For example, one might not prefer to share credit card information on a social networking site as readily as with a leading on-line retailer. To address these challenges, Higgins provides a software framework that delivers three technologies: (1) Identity Selector: First, it provides multi-platform 'identity selector' applications that end-users can use to sign-in to web sites and systems that are compatible with the emerging user-centric 'Information Card'-based (or 'i-card'-based) approach to authentication. This approach promises people fewer passwords, more convenience, and better security. An Information Card is a new, graphical way to refer to a collection of identity information that you might wish to send to a website or program. (2) Identity Provider: Second, it provides 'identity provider' web services that can issue i-cards as well as the code necessary to enable web sites and applications to accept i-cards. Software developers can incorporate this code into their applications to make it easier for their users to log-in to their sites. (3) Data Model: Third, it implements the Higgins Global Graph (HGG) data model and the Higgins Identity Attribute Service (IdAS). Developers now have a framework that provides an interoperability and portability abstraction layer over existing 'silos' of identity data. For the first time, IdAS makes it possible to 'mash-up' identity and social network data across highly heterogeneous data sources including directories, relational databases, and social networks. Technology built on this framework could allow users to login to their bank account with a secure authorization key, which would be automatically freshly generated for each visit. Users wouldn't need to remember or write down passwords, which can also be long and complex enough to be secure. Additionally, this same interface also could allow users to sign into their favorite wiki or blog with just one click. Higgins is not another identity protocol like OpenID, SAML, or WS-Trust; it is a framework that allows software developers to integrate and leverage multiple protocols within their applications.

Federated Identity Through the Eyes of the Deployer
Eve Maler and Marina Sum, Sun Developer Network

Why deploy federated identity? To date, it's mostly been used for cross-domain single sign-on (SSO) to save user time and hassle and to eliminate costly password resets. To protect the identity and application data being passed around, IdPs and SPs typically establish a circle of trust with technical and business agreements that define their respective responsibilities. Often, a circle of trust assumes a star-shaped topology with a single IdP and many SP spokes that trust the IdP but not necessarily each other. The IdP role is more complex because it must furnish the authentication infrastructure along with most of the security measures. SPs, looking to simplify by outsourcing to the IdP, expect to be offered toolkits that ease deployment. The choice of federated identity protocol determines the language in which the parties communicate—the forms and meaning of the messages. (1) SAML: The most comprehensive and widely deployed protocol is the Security Assertion Markup Language (SAML), currently at version 2.0. The SAML 2.0 design resulted from a merging of the SAML 1.1 capabilities, the SAML-based Shibboleth protocol that's in use in higher education, and the Liberty Alliance protocols known as the Identity Federation Framework (ID-FF). You might have come across some of those older protocols, which are still in active deployment. They represent unique languages because their syntaxes are mutually incompatible. (2) WS-Federation: A somewhat similar protocol that was developed independently is WS-Federation. The Microsoft genesis makes it most often chosen for IdPs and SPs that share a Microsoft-based identity and Web services platform. Microsoft's InfoCard protocol, which governs its Windows CardSpace implementation, offers a phishing-resistant means of Web authentication and attribute sharing that meshes well with the concept of SSO. To adopt the CardSpace paradigm, you must ensure that a special agent, called an identity selector, is deployed on your users' client systems. (3) OpenID: This protocol focuses on simplicity and ease of SP deployment, particularly for Web 2.0 sites. OpenID presumes a total lack of trust—anyone can create an OpenID identifier (a URI) and host an IdP. SPs that choose to accept OpenID logins do so without setting up trust relationships with IdPs in advance. Such a setup avoids burdening the process of rolling out an SP but limits your options in terms of partner trustworthiness and system security. (4) Sun Solutions: To help deployers who need multiple protocols or flexibility, Sun Java System Access Manager and its open-source twin OpenSSO have become polyglots. They work with SAML, ID-FF, and WS-Federation, but OpenSSO also offers an extension for OpenID; support for the InfoCard protocol through an extension is in the works.

Acid3: Putting Browser Makers on Notice, Again
Staff, WaSP Announcement

Developers at the Web Standards Project (WaSP) announced the release of Acid3, the latest in a line of tests designed to expose flaws in the implementation of mature Web standards in Web browsers. By making sure their software adheres to the test, the creators of these products can be more confident that their software will display and function with Web pages correctly both now and with Web pages of the future. The Acid3 Test is designed to test specifications for Web 2.0, and exposes potential flaws in implementations of the public ECMAScript 262 and W3C Document Object Model 2 standards. Collectively known as DOM Scripting, it is these technologies that enable advanced page interactivity and power many advanced web applications such as web-based email and online office applications. As a series of 100 mini-tests, Acid3 has already been found to expose flaws in all tested browsers, including Internet Explorer, Firefox, Opera, and Safari. WaSP hopes that Acid3 will prove useful to browser makers during the development of future versions of their products. WaSP has a history of such initiatives. In 1997, emeritus member Todd Fahrner, together with a group of crack Web developers dubbed the 'CSS Samurai,' created an 'Acid Test' that highlighted shortcomings in browser support for CSS. The Acid Test was instrumental in moving the industry much closer to the goal of consistent rendering of Web pages in different browsers. This was followed by Acid2 in 2005, designed to expose flaws in the implementation of mature Web standards such as HTML, CSS, and PNG. Acid3 builds on and extends this legacy to web applications in 2008. Founded in 1998, The Web Standards Project (WaSP) fights for standards that reduce the cost and complexity of development while increasing the accessibility and long-term viability of any site published on the Web. We work with browser companies, authoring tool makers, and our peers to deliver the true power of standards to this medium.

See also: the Acid3 web site

Microsoft's Interoperability Principles and IE8
Dean Hachamovitch, IEBlog

"We've decided that IE8 will, by default, interpret web content in the most standards compliant way it can. This decision is a change from what we've posted previously [about IE8 and 'Quirks mode']. Basically, all the browsers have a "Quirks" mode, and use it to offer compatibility with pages that pre-date modern standards. All browsers have a "Standards" mode, call it "Standards mode," and use it to offer a browser's best implementation of web standards. Each version of each browser has its own Standards mode, because each version of each browser improves on its web standards support. There's Safari 3's Standards mode, Firefox 2's Standards mode, IE6's Standards mode, and IE7's Standards mode, and they're all different. We want to make IE8's Standards mode much, much better than IE7's Standards mode... Our initial thinking for IE8 involved showing pages requesting "Standards" mode in an IE7's "Standards" mode, and requiring developers to ask for IE8's actual "Standards" mode separately. We made this decision, informed by discussions with some leading web experts, with compatibility at the top of mind. In light of the [Microsoft] Interoperability Principles, as well as feedback from the community, we're choosing differently. Now, IE8 will show pages requesting "Standards" mode in IE8's Standards mode. Developers who want their pages shown using IE8's "IE7 Standards mode" will need to request that explicitly, using the HTTP header/meta tag approach. Ray Ozzie, Microsoft chief software architect: "We have decided to give top priority to support for these new Web standards. In keeping with the commitment we made in our Interoperability Principles of being even more transparent in how we support standards in our products, we will work with content publishers to ensure they fully understand the steps we are taking and will encourage them to use this beta period to update their sites to transition to the more current Web standards supported by IE8..."

See also: the announcement

GridShib SAML Tools Version 0.3.0
Staff, GridShib Project Announcement

Developers have announced the release of GridShib SAML Tools Version 0.3.0. GridShib is an NSF-funded project to integrate the Globus Toolkit and Shibboleth. With both GridShib for Globus Toolkit and GridShib for Shibboleth installed, Globus Toolkit may securely request attributes from the Attribute Authority component of a Shibboleth Identity Provider. GridShib distributes four software components: GridShib for Globus Toolkit, GridShib for Shibboleth, GridShib Certificate Authority, and GridShib SAML Tools. GridShib SAML Tools v0.3.0 is the final release in the current development cycle, largely driven by the TeraGrid Science Gateway Use Case. The TeraGrid Science Gateway SAML extension is a software tool with a command-line interface (like grid-proxy-init) and a Java API that gateway developers can use to bind a SAML assertion to an X.509 proxy certificate. The SAML assertion includes end user identity and contact information that resource poviders can use for auditing, incident response, and access control. The GridShib SAML Tools require only Java 1.4 (or later) and Ant 1.6 (or later). Proxy certificates issued by the SAML Tools are compatible with GridShib for Globus Toolkit v0.6.0 Alpha (or later). Important new features of GridShib SAML Tools v0.3.0 include: (1) enhanced command-line interface; (2) new command-line options for the SAML Assertion Issuer Tool, including the option to output a DER-encoded ASN.1 structure; (3) new X.509 Binding Tool, to bind arbitrary content to a non-critical extension of an X.509 proxy certificate; (4) new SAML Security Info Tool, for examining the contents of X.509-bound SAML tokens; (5) expanded Java API, for producing and consuming SAML assertions and X.509 proxy certificates.

OASIS Open Reputation Management Systems (ORMS) Technical Committee
Staff, OASIS Announcement

OASIS has issued a Call for Participation in the newly formed Open Reputation Management Systems (ORMS) TC. The TC intends to develop an Open Reputation Management System (ORMS) that provides the ability to use common data formats for representing reputation data, and standard definitions of reputation scores. The system will not define algorithms for computing the scores. However, it will provide the means for understanding the relevancy of a score within a given transaction. The TC's output will enable the deployment of a distributed reputation systems that can be either centralized or decentralized with the ability for aggregators and intermediaries to be part of the business model. The group will develop use cases to gather requirements that ORMS will need to meet and understand the business and social impact of such a system. The members plan to develop a framework for reputation data gathering including: (1) Development of common data models for expressing reputation data; (2) XML Schema for representing ORMS data; (3) XML Schema for Reputation Score; (4) Development of standard way of exchanging reputation claims among systems; (5) Development of means of aggregating reputation data including delegation of claims generations and assertions; (6) Development of query/response communication protocols for exchanging reputation data in a trusted and secure fashion. This step may develop a new protocol, or extend current ones such as SAML, OpenID etc. The increasing reliance on the Internet as a medium for social interaction and online collaboration, and the emergence of converged networks with ubiquitous services that span different wire-line, wireless, mobile networks, devices, and users are placing new emphasis for developing reputation mechanisms for electronics based communities. The use of reputation systems has been proposed for various applications such as validating the trustworthiness of sellers and buyers in online auctions, detecting free riders in peer to peer networks, ensuring the authenticity of signature keys in a web of trust, supporting smarter searching of web sites, blogs, events, products, companies and other individuals.

Element Traversal Specification
Doug Schepers (ed), W3C Technical Report

Members of the W3C Web API WG have issued a Last Call Working Draft of the "Element Traversal Specification" as part of the Rich Web Clients Activity. The ElementTraversal interface was originally published as part of the SVG Tiny 1.2 specification in the SVG namespace. At the request of the SVG, CDF, JCP, and other groups, it was transferred to the WebAPI WG, and migrated to DOM and DOM namespace as a generic facility. The specification defines the ElementTraversal interface, which allows script navigation of the elements of a DOM tree, excluding all other nodes in the DOM, such as text nodes. It also provides an attribute to expose the number of child elements of an element. It is intended to provide a more convenient alternative to existing DOM navigation interfaces, with a low implementation footprint. The DOM Level 1 Node interface defines 11 node types, but most commonly authors wish to operate solely on nodeType 1, the Element node. Other node types include the Document element and Text nodes, which include whitespace and line breaks. DOM 1 node traversal includes all of these node types, which is often a source of confusion for authors and which requires an extra step for authors to confirm that the expected Element node interfaces are available. This introduces an additional performance constraint. Thus, ElementTraversal is an interface which allows the author to restrict navigation to Element nodes. It permits navigation from an element to its first element child, its last element child, and to its next or previous element siblings. Because the implementation exposes only the element nodes, the memory and computational footprint of the DOM representation can be optimized for constrained devices. The DOM Level 1 Node interface also defines the childNodes attribute, which is a live list of all child nodes of the node; the childNodes list has a length attribute to expose the total number of child nodes of all nodeTypes, useful for preprocessing operations and calculations before, or instead of, looping through the child nodes. The ElementTraversal interface has a similar attribute, childElementCount, that reports only the number of Element nodes, which is often what is desired for such operations.


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors