password
username
Sponsored by CakeMail, an email marketing software
Newsletter preview


XML Daily Newslink. Tuesday, 04 March 2008
A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS http://www.oasis-open.org
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.

http://xml.coverpages.org/HigginsV10-Release.html

----------------------------------------------------------------------

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.

http://developers.sun.com/identity/reference/techart/deployment.html

----------------------------------------------------------------------

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.

http://www.webstandards.org/press/releases/20080303/
See also the Acid3 web site: http://www.webstandards.org/acid3/

----------------------------------------------------------------------

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..."

http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx
See also the announcement: http://www.microsoft.com/presspass/press/2008/mar08/03-03WebStandards.mspx

----------------------------------------------------------------------

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.

http://www.gridvm.org/gridshib-saml-tools-v030.html
See also the GridShib SAML Tools Version 0.3.0 README: http://gridshib.globus.org/docs/gridshib-saml-tools-0.3.0/readme.html

----------------------------------------------------------------------

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 including security, privacy, threats and risks
requirements will also be developed. Explore the use of reputation
mechanisms in novel settings. The members plan to development 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.

http://lists.oasis-open.org/archives/tc-announce/200803/msg00001.html

----------------------------------------------------------------------

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.

http://www.w3.org/TR/2008/WD-ElementTraversal-20080303/
See also the W3C Web API Working Group: http://www.w3.org/2006/webapi

----------------------------------------------------------------------

XML Daily Newslink and Cover Pages are sponsored by:

BEA Systems, Inc. http://www.bea.com
EDS http://www.eds.com
IBM Corporation http://www.ibm.com
Primeton http://www.primeton.com
SAP AG http://www.sap.com
Sun Microsystems, Inc. http://sun.com

----------------------------------------------------------------------

XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter ***: newsletter-***@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/

----------------------------------------------------------------------