Cover Pages: XML Daily Newslink: Monday, 19 January 2009

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:
Sun Microsystems, Inc. http://sun.com

Headlines

Web Services Federation Language (WS-Federation) Version 1.2
W3C Invites Implementations of CURIE Syntax 1.0 Specification
Sieve Email Filtering: Sieves and Display Directives in XML
Sun Opens Netscape Server Source
Community Draft: OpenID Provider MultiAuth Extension
Enabling Virtual Federation With OpenSSO, Part 1: Introduction
Creating Hierarchical Data Structure Mashups

Web Services Federation Language (WS-Federation) Version 1.2
Marc Goodner and Anthony Nadalin (eds), OASIS Committee Draft

Members of the OASIS Web Services Federation (WSFED) Technical Committee have released an approved draft of the "Web Services Federation Language (WS-Federation) Version 1.2" specification for public review. The specification defines mechanisms to allow different security realms to federate, such that authorized access to resources managed in one realm can be provided to security principals whose identities are managed in other realms. While the final access control decision is enforced strictly by the realm that controls the resource, federation provides mechanisms that enable the decision to be based on the declaration (or brokering) of identity, attribute, authentication and authorization assertions between realms. The choice of mechanisms, in turn, is dependent upon trust relationships between the realms. While trust establishment is outside the scope of this document, the use of metadata to help automate the process is discussed. A general federation framework must be capable of integrating existing infrastructures into the federation without requiring major new infrastructure investments. This means that the types of security tokens and infrastructures can vary as can the attribute stores and discovery mechanisms. Additionally, the trust topologies, relationships, and mechanisms can also vary requiring the federation framework to support the resource's approach to trust rather than forcing the resource to change. The federation framework defined in this specification builds on WS-Security, WS-Trust, and the WS-* family of specifications providing a rich extensible mechanism for federation. The WS-Security and WS-Trust specification allow for different types of security tokens, infrastructures, and trust topologies. This specification uses these building blocks to define additional federation mechanisms that extend these specifications and leverage other WS-* specifications. The mechanisms defined in this specification can be used by Web service (SOAP) requestors as well as Web browser requestors. The Web service requestors are assumed to understand the WS-Security and WS-Trust mechanisms and be capable of interacting directly with Web service providers. The Web browser mechanisms describe how the WS-* messages (e.g. WS-Trust's RST and RSTR) are encoded in HTTP messages such that they can be passed between resources and Identity Provider (IP)/ Security Token Service (STS) parties by way of a Web browser client. This definition allows the full richness of WS-Trust, WS-Policy, and other WS-* mechanisms to be leveraged in Web browser environments... The assertions defined within this specification have been designed to work independently of a specific version of WS-Policy. At the time of the publication of this specification the versions of WS-Policy known to correctly compose with this specification are WS-Policy 1.2 and 1.5. Within this specification the use of the namespace prefix wsp refers generically to the WS-Policy namespace, not a specific version.

W3C Invites Implementations of CURIE Syntax 1.0 Specification
Mark Birbeck and Shane McCarron, W3C Technical Report

The W3C XHTML2 Working Group now invites implementation of the Candidate Recommendation of "CURIE Syntax 1.0: A Syntax for Expressing Compact URIs." This document defines a generic, abbreviated syntax for expressing URIs. The syntax is intended to be used as a common element by language designers. The intended audience for this document is Language designers, not the users of those Languages. This Candidate Recommendation version is based upon comments received during the last call period, upon work done in the definition of XHTML 2, and upon work done by the RDF-in-HTML Task Force, a joint task force of the Semantic Web Best Practices and Deployment Working Group and XHTML 2 Working Group. It is considered mature and stable by the working group. A record of how the comments from the last call period were addressed is available online, together with an implementation report ("CURIE Syntax 1.0 Implementation Report"). The working group intends to submit this document for consideration as a W3C Proposed Recommendation after 6-February-2009, provided that the following criteria are met: at least two interoperable implementations support all of the required features; all issues raised during the CR period against the document have received formal responses. Background: "More and more languages need a mechanism to permit the use of extensible name collections. These are primarily found in XML attribute values, but also found in other, similar spaces in non-XML languages (e.g., SPARQL). Typically, such extension mechanisms utilize the concept of scoping, where names are created within a unique scope, and that scope's collection is managed by the group that defines it. Using such a mechanism allows independent organizations to define names without the risk of collision. In many cases, language designers are attempting to use QNames for this extension mechanism. QNames do permit independent management of the name collection, and can map the names to a resource. Unfortunately, QNames are unsuitable in most cases because the use of QName as identifiers in attribute values and element content is problematic..." Some discussion is presented in ""Using Qualified Names (QNames) as Identifiers in XML Content," edited by Norm Walsh. "This specification addresses the problem by creating a new data type whose purpose is specifically to allow for the definition of scoped names that map to URIs in exactly this way. This type is called a 'CURIE' or a 'Compact URI'. Syntactically, CURIEs are a superset of QNames..."

Sieve Email Filtering: Sieves and Display Directives in XML
Ned Freed and Srinivas Saisatish Vedam (eds), IETF Internet Draft

The principal IETF RFC for "Sieve: An Email Filtering Language" (IETF RFC 5228) describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs. Some user interface environments have extensive existing facilities for manipulating material represented in XML. While adding support for alternate data syntaxes may be possible in most if not all of these environments, it may not be particularly convenient to do so. The obvious way to deal with this issue is to map sieves into XML, possibly on a separate backend system, manipulate the XML, and convert it back to normal Sieve format. The fact that conversion into and out of XML may be done as a separate operation on a different system argues strongly for defining a common XML representation for Sieve. This way different front end user interfaces can be used with different back end mapping and storage facilities. Another issue with the creation and manipulation of sieve scripts by user interfaces is that the language is strictly focused on describing email filtering operations. The language contains no mechanisms for indicating how a given script should be presented in a user interface. Such information can be represented in XML very easily so it makes sense to define a framework to do this as part of the XML format. A structured comment convention is then used to retain this information when the script is converted to normal Sieve format. Various sieve extensions have already been defined, and more are planned. The set of extensions available varies from one implementation to the next and may even change as a result of configuration choices. It is therefore essential that the XML representation of Sieve be able to accommodate Sieve extensions without requiring schema changes. It is also desirable that Sieve extensions not require changes to the code that converts to and from the XML representation. This specification defines an XML representation for sieve scripts and explains how the conversion process to and from XML works. The XML representation is capable of accommodating any future Sieve extension as long as the underlying Sieve grammar remains unchanged. Furthermore, code that converts from XML to the normal Sieve format requires no changes to accommodate extensions, while code used to convert from normal Sieve format to XML only requires changes when new control commands are added—a rare event. An XML Schema, Relax NG Schema, and a sample stylesheet to convert from XML format are also provided in the appendices.

Sun Opens Netscape Server Source
Charlie Martin, InfoQueue

Sun Microsystems announced that they are releasing a version of the Sun Java System Web Server version 7 as open source software under a BSD license. The Java Web Server is the same server previously known as the Netscape Enterprise Server (NES), iPlanet Web Server, Sun ONE Web Server, and Sun Java System Web Server. The Open Web Server version is from the current code base, but doesn't include some Sun administrative and modeling tools and some Java container support. This is a production quality high-capacity web server with full support of common Web protocols and interfaces, and plugins to support common FOSS application server and J2EE components such as JBoss and Glassfish. Now that it is available as open source, it should potentially compete with the Apache httpd server, especially for java and OpenSolaris installations. From the online description: "Open Web Server is derived from the core of Sun Java System Web Server 7.0. Open Web Server is a highly scalable multi-threaded HTTP engine capable of handling hundreds of thousands of simultaneous HTTP connections. Open Web Server includes common interfaces for adding dynamic content including SHTML, CGI, FastCGI, and its own native interface, NSAPI. With connector plugins Open Web Server can easily be used with popular Java application servers such as GlassFish, Geronimo, Tomcat, JBoss, and more. Open Web Server features support for access control, LDAP credential store, SSL, and Elyptic Curve Cryptography (ECC). Sometime ago, Sun announced that it would be open-sourcing 'core' components of the Sun Java System Web Server and the Sun Java System Web Proxy Server products. This source code is hosted under the OpenSolaris Web Stack project. Currently, not all of the functionality of Sun Java System Web Server 7.0 has been open sourced. In order to avoid confusion between the bits can be built from what has been open-sourced and the bits from the commercial product, the 'branding/name/identification' strings in the open-sourced bits have been changed from Sun Java System Web Server 7.0 to Open Source Web Server 1.0. Open Web Server is a mature software project with lineage dating to Netscape's Commerce Server. In the intervening years it has been known as Netscape Enterprise Server (NES), iPlanet Web Server, Sun ONE Web Server, and Sun Java System Web Server; its commercial counterpart which includes administration tools, integrated Java container and more monitoring tools still uses this name..." Open Web Server is licensed under the BSD license in order to make its technology as accessible as possible to the Web community.

Community Draft: OpenID Provider MultiAuth Extension
David Fuelling, OpenID Draft

A posting on the OpenID Specifications Discussion List announces the release of an "OpenID Provider MultiAuth Extension" specification, version -02. In a nutshell, the editor says: "the idea here is to protect end-users against a 'rogue OP' by providing a mechanism for a Claimed Identifier to mandate that an RP get valid auth assertions from two or more different OP's before giving access to RP-protected resources." From the abstract: The document specifies an extension to OpenID Authentication 2.0 Discovery. This extension allows a Claimed Identifier to specify that an RP should receive valid OpenID Authentication assertions from at least two different OP's before the RP may grant access to protected resources. OpenID Authentication 2.0 currently only specifies a single authoritative OP for a given Claimed Identifier. This restriction poses a modest security risk from the perspective that a rogue OP (or a rogue employee at an OP) might surreptitiously operate on behalf of a user without that user's knowledge or consent. By providing OpenID users with the ability to prevent this type of attack, users will be able to mitigate a common concern with the OpenID protocol as it stands today. Extension Overview: (1) Discovery is performed on an OpenID Claimed Identifier resulting in either an XRDS or HTTP document, either of which will specify information to indicate that the Claimed Identifier supports this extension; (2) Discovery documents supporting this extension MUST indicate at least two OpenID Endpoint URL's, each of which has a correctly populated 'local_id' attribute representing the "OP-Local Identifier" for a given OP Endpoint (3) Relying Parties utilizing this information and supporting this extension MUST perform OpenID Authentication on ALL specified OpenID endpoints (using the specified 'local_id') before granting access to RP-protected resources; (4) If OpenID Authentication is successful on ALL specified OP Endpoints using the associated Claimed Identifier for each OP) then OpenID Authentication SHOULD proceed per usual. (5) If OpenID Authentication is not successful on ALL specified OP Endpoint's (using the associated Claimed Identifier for each OP), then OpenID Authentication SHOULD fail, unless alternate OpenID Authentication mechanisms are specified in the XRDS/HTTP Discovery documents...

Enabling Virtual Federation With OpenSSO, Part 1: Introduction
Mike Hortobagyi and Marina Sum, Sun Developer Network

As described in a 2007 commentary, identity federation is an approach that authenticates users across multiple sites within a company (intranets) or independent and disparate domains (extranets) through open standards: "The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration." At its core, identity federation encompasses authentication, authorization, and audit (AAA), user identity data (attributes), user provisioning, and identity Web services. Identity federation is playing an increasingly important role in the identity life cycle of enterprises, thanks to its strategic business value across organizations. This article, Part 1 of a two-part series, elaborates on the challenges businesses are facing with identity federation. Also introduced are the virtual-federation capability and its benefits in OpenSSO, along with an example of the process flow. OpenSSO is a Sun-sponsored, open-source project that offers core identity capabilities, including security for Web applications, single sign-on (SSO), federation, and identity services. Based on Sun Java System Access Manager, the project is the foundation for Sun OpenSSO Enterprise 8, the commercial release. In addition to working with enterprise-focused standards like SAML 2.0, XACML, and WS-Federation, OpenSSO works with community-based subproject protocols like OpenID and Information Cards... Sun OpenSSO Enterprise, tailored for identity federation and Web access management, tackles the issues with a new capability: virtual federation. That capability federates legacy applications by enabling them to securely "push" identity information (authentication, profile, and transactional attributes) to OpenSSO, which then transmits the data to external partners through standard federation protocols. Additionally, you can manage federated applications to external partners with OpenSSO as the centralized federation component in your company's identity infrastructure. At a high level, virtual federation is a simple, secure mechanism for one application to transfer identity information to another in a different domain with the Security Assertion Markup Language (SAML) 2.0 protocol. Subsequently, you can easily federate applications or services with external partners through a single OpenSSO instance. Virtual federation brings a secure passage of identity information along with authentication to OpenSSO, which then acts as a proxy for the data transfer to external partners through common standards. Currently, virtual federation only works with the following but will work with other federated protocols and profiles in the future: SAML 2.0 browser-based transient federation and federated SSO, and browser-based HTTP GET and POST binding mechanisms of the SAML 2.0 protocol. Virtual federation offers the following key benefits: (1) A loosely coupled, federated application can extend identity federation capabilities to that application instead of following the more traditional model of extracting data from a preconfigured local repository. (2) Only one OpenSSO instance is necessary to federate multiple applications. (3) At a lower level, OpenSSO instances can act as a SAML 2.0 standards-compliant "protocol gateway." That means you can authenticate users and securely transmit identity information through the SAML 2.0 infrastructure. (4) Because virtual federation is a lightweight OpenSSO component that requires only a small client API, you can save many integration efforts aimed at federating legacy applications or services that are not natively federation-capable.

Creating Hierarchical Data Structure Mashups
Michael M. David, DevX.com

ANSI SQL can naturally perform full multi-path hierarchical data query processing that far exceeds the single linear path processing performed by XPath and XQuery today. A previous DevX.com article "Navigationless Database XML: Hierarchical Data Processing" covers the basics of full hierarchical processing and describes how SQL can inherently perform this advanced processing. While the previous article concentrated on using the SQL LEFT OUTER JOIN operation to model and process hierarchical structures (both logical relational and physical XML structures) in individual views, this article demonstrates how you can join these heterogeneous hierarchically complex structure types together dynamically and seamlessly into a larger hierarchical structure. You'll also see how standard SQL hierarchical structure joining also naturally supports unrestricted data structure mashups that still follow standard hierarchical principles. A powerful and advanced new hierarchical data modeling capability makes this possible. When integrating relational and XML data, it is important to get the correct result without any data loss. Unfortunately this has not yet been achieved. Today's processing introduces inaccurate results that inhibit correct hierarchical XML processing in databases. However, by modeling relational flat data as hierarchical structures, it becomes possible to integrate relational data with XML without any loss of data accuracy... A number of advanced operational SQL features and capabilities occur through the processing phases shown [see figure] that are not present in other XML query languages. This is possible because the expanded LEFT OUTER JOIN data modeling consists of the hierarchical data modeling instructions that define the full structure enable structure-aware processing. When separate structures are joined into a single hierarchical structure so are their separate LEFT OUTER JOIN sequences, automatically performing this complex real-time processing required for structure-aware processing. By determining which pathways of the query are not necessary, the unnecessary pathway processing can be removed easily and precisely by eliminating the join operation for the unneeded nodes. This global optimization process is not being performed elsewhere today because XML today uses only user navigation and the processing logic used contains procedural coding instructions as with XQuery's user-specified looping logic, making global optimization difficult. In addition, XML processors like XQuery allow non-hierarchical operations such as the inner join operation which invalidates hierarchical structures... Mashing up structures should not change their basic structure. Changes to the basic data structure should be done by transformation operations. The new data modeling semantics of linking below the root for data mashups also helps supports advanced new transformation capabilities.


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

Headlines

Sponsors