Cover Pages: XML Daily Newslink: Wednesday, 09 June 2010

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:
Oracle Corporation http://www.oracle.com

Headlines

W3C First Public Draft: Web Services SOAP Assertions (WS-SOAPAssertions)
OAuth 2.0 Support for the Kerberos V5 Authentication Protocol
CSS Generated Content for Paged Media Module
OASIS Fifteen-Day Review for SCA-Bindings TC Specifications
Tracking of Emergency Patients (EDXL-TEP) Messaging Standard
Creating Mobile Web Applications with HTML 5: Multi-Threaded JavaScript
New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)

W3C First Public Draft: Web Services SOAP Assertions (WS-SOAPAssertions)
Doug Davis, Ashok Malhotra, Katy Warr, Wu Chou (eds), W3C Technical Report

Members of the W3C Web Services Resource Access (WS-RA) Working Group have published a First Public Working Draft for the specification Web Services SOAP Assertions (WS-SOAPAssertions). This specification defines two WS-Policy assertions that can be used to advertise the requirement to use a certain version of SOAP in message exchanges.

From the Introduction: Using the 'Web Services Policy (WS-Policy) 1.5 - Framework and Web Services Policy (WS-Policy) 1.5 - Attachment specifications, an endpoint can indicate support for a variety of features. Two endpoints can then determine if they share compatible features through the policy intersection algorithm defined by the WS-Policy framework. This allows for a programmatic way to locate interoperable endpoints... However, one key aspect of the message exchanges is whether either endpoint requires the use of SOAP 1.1 or SOAP 1.2. While this information might be obtainable through examination of a WSDL document, or implied through some out of band knowledge, there is no way to make this determination during the application of the policy intersection algorithm. This specification defines two new policy assertions that allows for this critical piece of information to be available during normal policy processing..."

'Web Services Policy 1.5 - Framework' itself defines a framework and a model for expressing policies that refer to domain-specific capabilities, requirements, and general characteristics of entities in a Web services- based system. A policy is a collection of policy alternatives. A policy alternative is a collection of policy assertions. A policy assertion represents a requirement, capability, or other property of a behavior. A policy expression is an XML Infoset representation of its policy, either in a normal form or in its equivalent compact form. Some policy assertions specify traditional requirements and capabilities that will manifest themselves in the messages exchanged(e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation in the messages exchanged, yet are relevant to service selection and usage (e.g., privacy policy, QoS characteristics)... The Framework specification does not cover discovery of policy, policy scopes and subjects, or their respective attachment mechanisms. A policy attachment is a mechanism for associating policy with one or more policy scopes...

The W3C Web Services Resource Access (WS-RA) Working Group was chartered to produce W3C Recommendations for a set of Web Services specifications by refining the WS-Transfer, WS-ResourceTransfer, WS-Enumeration, WS-MetadataExchange and WS-Eventing Member Submissions. These specifications define SOAP-based mechanisms for interacting with the XML representation behind a resource-oriented Web Service, accessing metadata related to that service, as well as a mechanism to subscribe to events related to that resource. WS-Transfer defines the basic Create, Read, Update, Delete (CRUD) operations against resource-oriented Web Service data. WS-ResourceTransfer enhances these operations, through the extensibility points of WS-Transfer, with the addition of fragment and batched access. WS-Enumeration provides a protocol that allows a resource to provide a context, called an enumeration context, to a consumer that represents a logical cursor through a sequence of data items. WS-Eventing allows interested parties to subscribe to a series of notifications from a resource oriented Web Service. WS-MetadataExchange defines a mechanism by which metadata about a Web Service can be retrieved. When used in conjunction with WS-Transfer, WS-ResourceTransfer and WS-Enumeration, this metadata can be accessed and managed just like any other Web Service..."

OAuth 2.0 Support for the Kerberos V5 Authentication Protocol
Thomas Hardjono (ed), IETF Internet Draft

Thomas Hardjono (MIT Kerberos Consortium) has released an initial level -00 Internet Draft for OAuth 2.0 Support for the Kerberos V5 Authentication Protocol. This I-D proposes an OAuth2.0 profile for Kerberos v5. It compares the Kerberos protocol flow with the OAuth protocol flow and as far as possible map the relevant parameters in Kerberos to OAuth parameters. It proposes the use of the OAuth 2.0 message flows and its tokens to carry Kerberos TGTs and Service Tickets in an opaque manner... The aim of this draft is to identify and define mechanisms that would allow a high degree of interoperability between OAuth 2.0 and Kerberos. As such, it is not the intent of the current work to replace OAuth 2.0, but instead to allow organizations to deploy OAuth 2.0 compliant Authorization Servers and Resource Servers, while retaining (and value-adding to) their Kerberos infrastructure in the back-end.

From the document Introduction: "There are a number of reasons why Oauth 2.0 support for the Kerberos protocol would be useful to the security industry. First, there is a large degree of similarity at the protocol design level and intended functions between Oauth 2.0 and Kerberos. There is also strong similarities in the entities involved in OAuth2.0 and Kerberos, albeit OAuth focuses on the application layer (above the HTTP layer). Access to a service requires the client to obtain an Access Token (or Service Ticket in Kerberos), while the Refresh Token (or Ticket Granting Ticket in Kerberos) is used to limit the number of re-authentications by the user seeking to use the same service.

Secondly, easily upwards of 60% of medium to large Enterprises today use the Kerberos protocol in one form or another (proprietary implementations or open source), for various authentication requirements. These range from user-logons at the operating system level, to Web-SSO and to server-to-server authentication at the backend infrastructure. Support for Kerberos is built into various operating systems and open-source distributions (e.g. Windows, RedHat, Open Solaris, Ubuntu, etc), and the majority of browsers support some Kerberos functions. Allowing organizations to place Outh 2.0 servers as a front-end layer allows them to further re-use their existing Kerberos infrastructure, thereby allowing easier adoption of Oauth 2.0 within these organizations.

Thirdly, there are a number similarities in intended functions between Kerberos and OAuth 2.0. Any OAuth 2.0 function that can re-use Kerberos functionality and code may provide the developer with faster development time. Finally, interoperability between OAuth2.0 and Kerberos is highly desired from a deployment perspective. There are a number of ways to achieve such interoperability. For example, OAuth2.0 opaque tokens and other structures can be used to transport Kerberos messages. Transporting or tunneling Kerberos above other protocols is not a new idea. Various other protocols have previously been used to transport Kerberos message structures opaquely in order to satisfy certain security and deployment constraints..."

CSS Generated Content for Paged Media Module
Håkon Wium Lie (ed), W3C Technical Report

Members of the W3C Cascading Style Sheets (CSS) Working Group, part of the Style Activity, have published a Working Draft for CSS Generated Content for Paged Media Module, updating the previous Working Draft of 2007-05-04. This CSS module describes features often used in printed publications. Most of the specified functionality involves some sort of generated content where content from the document is adorned, replicated, or moved in the final presentation of the document. Along with two other CSS3 modules (multi-column layout and paged media), this module offers advanced functionality for presenting structured documents on paged media. This specification only applies to the 'print' media type. Some of the proposed functionality (e.g., hyphenation, the new list style types, and border segments) may also used with other media types... [Examples follow]

Running headers and footers: To aid navigation in printed material, headers and footers are often printed in the page margins. The 'CSS3 Module: Paged Media' document describes how to place headers and footers on a page, but not how to fetch headers and footers from elements in the document. This specification offers two ways to achieve this. The first mechanism is named strings which copies the text (without style, structure, or replaced content) from one element for later reuse in margin boxes. The second mechanism is running elements which moves elements (with style, structure, and replaced content) into a margin box....

Leaders: A leader is a visual pattern that guides the eye. Typically, leaders are used to visually connect an entry in a list with a corresponding code. For example, there are often leaders between titles and page numbers in a table of contents (TOC). Another example is the phone book where there are leaders between a name and a telephone number. In CSS3, a leader is composed of series of glyphs through the 'leader()' value on the 'content' property... Cross-references: It is common to refer to other parts of a document by way of a section number (e.g., "See section 3.4.1"), a page number (e.g., "See discussion on page 72"), or a string (e.g., "See the chapter on Europe"). Being able to resolve these cross-references automatically saves time and reduces the number of errors...

Footnotes: A footnote is a note typically placed at the bottom of a page that comments on or cites a reference, but he rendering of footnotes is complex. Due to the typographic traditions of footnotes, some new functionality is required to support footnotes in CSS... Image resolution: Image resolution, as the term is used in this document, means pixels per physical length, e.g., pixels per inch. Some image formats can record information about the resolution of images; however, the information can also be wrong, in which case it should be ignored. The 'image-resolution' and 'background-image-resolution' properties are introduced to determine the correct resolution of images. [Other supported features: Page marks and bleed area; Bookmarks; CMYK colors; Styling blank pages; Page floats; Advanced multi-column layout; Advanced multi-column layout...]"

See also: the W3C Style Activity

OASIS Fifteen-Day Review for SCA-Bindings TC Specifications
Simon Holdsworth and Anish Karmarkar (eds), OASIS Public Review Drafts

Members of the OASIS Service Component Architecture / Bindings (SCA-Bindings) Technical Committee have released three specifications for 15-day public review through June 23, 2010. This TC was chartered "to standardize bindings for the SCA services and references to various communication protocols, technologies and frameworks. For each SCA binding technology this TC is evolving the respective starting point contribution documents to produce one or more specification documents, XML Schema definition documents, possible WSDL documents, and possible language dependant artifacts as appropriate, from which compliant tools and runtimes for that SCA binding technology can be built."

Service Component Architecture Web Service Binding Specification Version 1.1 applies to the services and references of an SCA composite, per SCA-Assembly. It defines the manner in which a service can be made available as a web service, and in which a reference can invoke a web service. This binding is a WSDL-based binding; that means it either references an existing WSDL binding or specifies enough information to generate one. When an existing WSDL binding is not referenced, rules defined in this document specify how to generate a WSDL binding.

Service Component Architecture JMS Binding Specification Version 1.1 specifies the means by which SCA composites and components, as defined in the SCA Assembly Specification, connect to and access services using a messaging protocol. The connectivity is based on the Java Messaging Service and is provided by a binding.jms element which applies to the references and services of an SCA component or composite. The JMS binding provides JMS-specific details of the connection to the required JMS resources. It supports the use of Queue and Topic type destinations. The binding is especially well suited for use by services and references of composites that are directly deployed, as opposed to composites that are used as implementations of higher-level components. Services and references of deployed composites become system-level services and references, which are intended to be used by non-SCA clients."

Service Component Architecture JCA Binding Specification Version 1.1 specifies the means by which SCA composites and components, as defined in the SCA Assembly Specification, connect to and access services provided by Enterprise Information Systems (EIS). The connectivity is based on the Java EE Connector Architecture (JCA) specification version 1.5, and is provided via a binding.jca element which applies to the references and services of an SCA composite or SCA component. The connection to exchange data with the EIS is characterized by two sets of configuration parameters, the connection and interaction parameters. The former set determines the location of the target system the latter determines characteristics that need to be specified to invoke one specific service available at the endpoint. JCA Binding model captures these parameters as separate sets to allow their reuse and reconfiguration..."

See also: the OASIS announcement

Tracking of Emergency Patients (EDXL-TEP) Messaging Standard
EDXL-TEP Steering Committee, Draft Requirements Specification

As described in a transmittal cover letter from DHS (Denis Gusty) and EIC (Donald Ponikvar), the submission packet for a new EDXL Tracking of Emergency Patients (EDXL-TEP) standard has been conveyed to the OASIS Emergency Management Technical Committee (EM-TC). The document is Draft Version 2.2 of Emergency Data Exchange Language (EDXL) Requirements Statement and Draft Messaging Specification for the PHASE I - Tracking of Emergency Patients (EDXL-TEP) Messaging Standard. It is subtitled as Precursor to Phase II: Tracking of Emergency Clients (EDXL-TEC), formerly 'EDXL-TEV' Tracking of Emergency Victims. The document was prepared by Evolution Technologies, Inc. at the direction of the DHS S&T-OIC EDXL Program, as defined by the EDXL Practitioner Steering Group and TEP Steering Committee. Associated material includes a Data Dictionary, EDXL-TEP Project Initiation Document (PID), EDXL-TEP Stakeholder Issues List, EDXL-TEP Participants List, etc.

These documents have been submitted ('requirements handoff') for standards review and formalization by the OASIS EM-TC under the OASIS process. The documents present the practitioner requirements for an EDXL-TEP standard which will provide the ability for seamless patient tracking across disparate locations, organizations, and systems during mass casualty, cross-jurisdiction incidents, as well as common day-to-day incidents. The Emergency Data Exchange Language (EDXL) suite includes CAP (Common Alerting Protocol), HAVE (Emergency Data Exchange Language Hospital AVailability Exchange - HAVE), EDXL-DE (Emergency Data Exchange Language Distribution Element), and EDXL-RM (Emergency Data Exchange Language Resource Messaging).

EDXL-TEP is an XML messaging standard primarily for exchange of emergency patient and tracking information from patient encounter through hospital admission or release. TEP supports patient tracking across the EMS incident continuum of care, as well as evacuations from hospitals and day to day hospital patient transfers, providing real-time information to responders, emergency management, coordinating organizations and care facilities involved in incidents and the chain of care and transport... Though requirements and inputs to this standard have been driven out through cross-profession emergency support practitioners and expressed in U.S.-based language and terms, the intent of this effort is to drive a public, international XML-based standard. This format is intended to be used collaboratively with other EDXL standards, and may be used over any data transmission system, including but not limited to the Simple Object Access Protocol (SOAP) Hypertext Transfer Protocol (HTTP) binding.

The TEP purpose embraces larger Phase II effort objectives for tracking everyone affected by and requiring emergency service or assistance as a result of a mass casualty incident, but is aimed at increased effectiveness of emergency medical services and management, patient tracking, and continued patient care preparedness during emergency care. TEP is driven by cross-profession practitioner needs (Practitioner Steering Group and expanded stakeholder groups), and led by the National Association of State EMS Officials (NASEMSO). It supports select goals of the HHS-Agency for Health and Research Quality (AHRQ) and gaps identified by the Health Information Technology Standards Panel (HITSP)..." [cache/archive]

Creating Mobile Web Applications with HTML 5: Multi-Threaded JavaScript
Michael Galpin, IBM developerWorks

Web applications have traditionally been stuck in a single-threaded world. This really limited developers in what they could do in their code, since anything too complicated risks freezing up the UI of the application. Web Workers have changed all of that by bringing multi-threading to Web applications. This is particularly useful for mobile Web applications where most of the application logic is client-side.

Multi-threaded or concurrent programming is nothing new to most developers. It is supported, in one way or another, in most modern programming languages. However, JavaScript is not one of the languages that supports concurrent programming. Its creator thought that it was too problematic and unnecessary for a language like JavaScript that was designed for performing simple tasks on Web pages. However, as Web pages have evolved into Web applications, the complexity level of tasks done with JavaScript has grown to put JavaScript on par with any other language. At the same time, developers working in other languages that support concurrent programming have often suffered and struggled with the extraordinarily high complexity that comes along with concurrent primitives like threads and mutexes.

In this article, you will learn how to work with Web Workers and discover which tasks are most appropriate for them. You will see how you can use with other HTML 5 technologies to increase the efficiency of using those technologies...

The Web Worker specification is not just about adding concurrency to JavaScript and Web browsers; it is about doing this in a smart way that will empower developers without giving them a tool that causes problems. For example, desktop application developers have used multi- threading for years to let their applications access I/O resources without freezing the UI while they wait for these resources. However, such applications often suffer when these multiple threads change shared resources (including the UI) which leads to applications that freeze up or crash. With Web Workers, this cannot happen. The spawned thread does not have access to the same resources as the main UI thread. In fact, the code in the spawned thread cannot even be in the same file as the code that is executed by the main UI thread..."

New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
Paul Hoffman and Jim Schaad (eds), IETF Approved RFC

The Internet Engineering Steering Group (IESG) announced approval of the New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) as an IETF Informational RFC (Request for Comments 5912). "The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax...

The modules in this document use the object model available in the 2002 ASN.1 documents to a great extent. Objects for each of the different algorithm types are defined. Also, all of the places where the 1988 ASN.1 syntax had ANY holes to allow for variable syntax now use objects.

Much like the way that the PKIX and S/MIME working groups use the prefix of id- for object identifiers, this document has also adopted a set of two-, three-, and four-letter prefixes to allow for quick identification of the type of an object based on its name. This allows, for example, the same back half of the name to be used for the different objects. Thus, 'id-sha1' is the object identifier, while 'mda-sha1' is the message digest object for 'sha1'. One or more object sets for the different types of algorithms are defined. A single consistent name for each different algorithm type is used. For example, an object set named PublicKeys contains the public keys defined in that module. If no public keys are defined, then the object set is not created. When importing these object sets into an ASN.1 module, one needs to be able to distinguish between the different object sets with the same name.

Related: New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME has also been issued as an RFC (Request for Comments 5911). "The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax..."


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

Headlines

Sponsors