Cover Pages: XML Daily Newslink: Monday, 17 May 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

IETF Publishes First Public Working Draft for OAuth Use Cases
W3C Audio Incubator Group: Advanced Audio Functionality in Web Browsers
Review: Test Assertions for the SCA Policy Framework 1.1 Specification
State Chart XML (SCXML): State Machine Notation for Control Abstraction
The 'mailto' URI Scheme: Improving Compatibility with IRIs
Preservation Metadata: PREMIS in METS Toolbox
Smart Credit Cards Finally Arrive in U.S.
Android Surges Into Second Place

IETF Publishes First Public Working Draft for OAuth Use Cases
Zachary Zeltsan (ed), IETF Internet Draft

On May 17, 2010, the Internet Engineering Task Force (IETF) published an initial level -00 Informational Internet Draft for OAuth Use Cases. The IETF Open Authentication Protocol (OAuth) Working Group was chartered to produce one or more documents suitable for consideration at IETF Proposed Standard level that will build upon OAuth 1.0 to (a) improve the terminology used; (b) embody good security practice, or document gaps in its capabilities, and propose a path forward for addressing the gap; (c) promote interoperability; (d) provide guidelines for extensibility.

The OAuth Protocol "provides a method for making authenticated HTTP requests using a token — an identifier used to denote an access grant with specific scope, duration, and other attributes. Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. OAuth defines multiple flows for obtaining a token to support a wide range of client types and user experience." The goal in the new "OAuth Use Cases" document is to initiate discussion that will lead to defining a set of the use cases that the OAuth specifications should support. The need for documenting the OAuth use cases was discussed at previous OAUTH Working Group virtual meetings, on the group's mailing list, and at the IETF 77 plenary.

Examples of use cases follow (in summary). (1) User-Agent Flow: A Client application residing in a user-agent accesses protected resource on user's behalf. (2) Web Server Flow: A client, which is a part of the web server application, accesses protected resource on user's behalf. User does not need to share authentication credentials with the client. (3) Device Flow: A Client executing on a device that does not have an easy data-entry method accesses a protected resource on user's behalf. (4) Username and Password Flow: A trusted client accesses the end user's resource on her or his behalf using the end user's username and password. The client does not need to store the end user's username and password permanently. (5) Client Credentials Flow: A client that is not acting on behalf of a separate resource owner accesses a protected resource. (6) Assertion Flow: A client exchanges an existing assertion (e.g., SAML assertion) for an access token, which it uses to access the protected resource. The client could be the resource owner or could be acting on the resource owner's behalf.

(7) Content sharing: Enable organizing and sharing information among the end users. For example, a Web user (resource owner) can grant data access to a pre-defined set of users. This can be done with the use of a special OAuth client (content manager) which serves as a proxy between the end-users and the Web servers that host the resources related to the project. (8) SIP authentication, establishment of an MSRP session: A client that implements text chat using asynchronous HTTP requests accesses on behalf of an end user her or his protected resources on a SIP server. (9) SIP authentication, gateway for browser-based VoIP applets: A client that implements a VoIP client as a browser applet accesses the end user's SIP resources on her or his SIP server and on the end user's behalf. (10) Use case Access Token Exchange: A client performs on an end user's behalf multi-layered services i.e., the services where one service requires execution of another service that requires authentication. (11) Use case for signature with asymmetric secret: A client, that does not have a shared secret with a server storing a protected resource, accesses the protected resource on end user's behalf..."

W3C Audio Incubator Group: Advanced Audio Functionality in Web Browsers
Staff, W3C Announcement

W3C has announced the creation of a new Audio Incubator Group, whose mission is to explore the possibility of starting one or more specifications dealing with various aspects of advanced audio functionality, including reading and writing raw audio data, and synthesizing sound or speech. The Audio Incubator Group will engage the various constituents of such specifications, including musicians, audio engineers, accessibility experts, user-interface designers, implementers, and hardware manufacturers, to collect use cases and requirements on what can and should be done for various specifications at different levels of priority, and deliver one or more reports including recommendations for specification work items.

Background: "Many Web browsers include the ability to play back prerecorded audio files, but do not commonly include the ability for client-side alteration or synthesis of the audio, or programatic access to the raw audio data (such as tempo or pitch). Raw audio data can be used to synchronize, visualize, or enhance sound information for purposes of accessibility, analysis, or entertainment. Sound synthesis can be used to enhance user interfaces, synthesize speech, or produce music. Adding advanced audio capabilities to user agents has the possibility to add new realms of functionality available to Web developers and designers. This is an area which has not yet been explored thoroughly on the Web platform, but which has great potential due to the existing technology available on desktop platforms.

The scope of this incubator group includes: (1) Engaging the diverse communities who will develop, use, or otherwise benefit from Web audio; (2) Developing use cases and requirements for future W3C specifications; (3) Profiling the various audio capabilities of different devices, such as mobile phones, desktop and laptop computers, televisions, and other environments where future specifications might be expected to be implemented; (4) Developing and evaluating prototype implementations to explore possibilities; (5) Creating demos and other means of raising awareness about this activity; (6) Writing preliminary specifications which may be further developed as Recommendation-track deliverables of a working group; (7) Discussing existing specifications and functionality, such as the work of the HTML, SYMM, and Voice Browser Working Groups, or relevant work done outside W3C...

The following W3C Members have sponsored the charter for this group: Mozilla Foundation, PUC-Rico, BBC, and Google. The Audio Incubator Group will be considered successful if it delivers one or more reports that lead to specifications which meet the needs of the different constituencies considered. For example, if audio content creators and implementers agree on a set of audio APIs, especially those which can benefit from native hardware functionality, and which are subsequently specified and implemented, this incubator will be considered successful."

Review: Test Assertions for the SCA Policy Framework 1.1 Specification
David Booz, Mike Edwards, Ashok Malhotra (eds), OASIS Public Review Draft

Members of the OASIS Service Component Architecture / Policy (SCA-Policy) Technical Commmittee have approved a Committee Draft 01 specification for public review through July 16, 2010: Test Assertions for the SCA Policy Framework 1.1 Specification.

The document defines the Test Assertions for the SCA Policy Framework specification (SCA Policy Framework Version 1.1). The Test Assertions represent the testable items relating to the normative statements made in the SCA Policy Framework specification. The Test Assertions provide a bridge between the normative statements in the specification and the conformance TestCases that are designed to check that an SCA runtime conforms to the requirements of the specification. The test assertions in this document follow the format defined in the draft "OASIS Test Assertion Guidelines" specification (November 2008).

"SCA Policy Framework Version 1.1" describes the SCA framework and its usage... The capture and expression of non-functional requirements is an important aspect of service definition and has an impact on SCA throughout the lifecycle of components and compositions. SCA provides a framework to support specification of constraints, capabilities and QoS expectations from component design through to concrete deployment... The term Policy is used to describe some capability or constraint that can be applied to service components or to the interactions between service components represented by services and references. An example of a policy is that messages exchanged between a service client and a service provider have to be encrypted, so that the exchange is confidential and cannot be read by someone who intercepts the messages...

In SCA, services and references can have policies applied to them that affect the form of the interaction that takes place at runtime. These are called interaction policies. Service components can also have other policies applied to them, which affect how the components themselves behave within their runtime container. These are called implementation policies. How particular policies are provided varies depending on the type of runtime container for implementation policies and on the binding type for interaction policies. Some policies can be provided as an inherent part of the container or of the binding — for example a binding using the https protocol will always provide encryption of the messages flowing between a reference and a service. Other policies can optionally be provided by a container or by a binding. It is also possible that some kinds of container or kinds of binding are incapable of providing a particular policy at all. In SCA, policies are held in policySets, which can contain one or many policies, expressed in some concrete form, such as WS-Policy assertions. Each policySet targets a specific binding type or a specific implementation type. PolicySets are used to apply particular policies to a component or to the binding of a service or reference, through configuration information attached to a component or attached to a composite..."

See also: the OASIS announcement

State Chart XML (SCXML): State Machine Notation for Control Abstraction
Jim Barnett, Rahul Akolkar, RJ Auburn, Michael Bodell (eds), W3C TR

The W3C Voice Browser Working Group has published a Working Draft for State Chart XML (SCXML): State Machine Notation for Control Abstraction. A color-coded diff-marked version relative to the previous 2009-10-29 Working Draft is also available for comparison purposes. The main differences from the previous draft are the removal of the 'anchor' element, a revision of the interpretation algorithm, and addition of a brief description on DOM Event I/O Processor.

State Chart XML (SCXML) is a general-purpose event-based state machine language that can be used in many ways, including: (1) As a high-level dialog language controlling VoiceXML 3.0's encapsulated speech modules -- voice form, voice picklist, etc; (2) As a voice application metalanguage, where in addition to VoiceXML 3.0 functionality, it may also control database access and business logic modules; (3) As a multimodal control language in the MultiModal Interaction framework, combining VoiceXML 3.0 dialogs with dialogs in other modalities including keyboard and mouse, ink, vision, haptics, etc; it may also control combined modalities such as lipreading (combined speech recognition and vision) speech input with keyboard as fallback, and multiple keyboards for multi-user editing. (4) As the state machine framework for a future version of Call Control Extensible Markup Language (CCXML); (5) As an extended call center management language, combining CCXML call control functionality with computer-telephony integration for call centers that integrate telephone calls with computer screen pops, as well as other types of message exchange such as chats, instant messaging, etc; (6) As a general process control language in other contexts not involving speech processing.

SCXML combines concepts from CCXML and Harel State Tables. CCXML is an event-based state machine language designed to support call control features in Voice Applications, specifically including VoiceXML but not limited to it. The CCXML 1.0 specification defines both a state machine and event handing syntax and a standardized set of call control elements. Harel State Tables are a state machine notation that was developed by the mathematician David Harel and is included in UML. They offer a clean and well-thought out semantics for sophisticated constructs such as a parallel states. They have been defined as a graphical specification language, however, and hence do not have an XML representation... SCXML is defined in terms of modules, which define logical units of functionality. Modules are customized and combined into profiles, each of which can be thought of as defining a variant of the language. This modularity allows implementations flexibility in selecting the features that they want to support. It is particularly intended to allow them the choice of which data manipulation language (e.g., ECMAScript, XPath) to embed. At this point, only support for the most limited profile is mandatory.

The DOM Event I/O processor handles communication between SCXML markup and markup in other namespaces in mixed-markup XML documents. An example of this would be a document containing both SCXML and HTML markup. In such a case, each language retains its own context and its own independent semantics. For example, SCXML's event processing algorithm is not affected by the fact that there is HTML markup elsewhere in the document. It is however useful for the two languages to be able to communicate by sending events back and forth, so that the HTML markup can notify SCXML when the user clicks on a button, and the SCXML markup can notify HTML when it is time to place a certain field in focus, etc. The DOM Event I/O processor handles this communication by means of DOM Events, which are a general means for information propagation in XML documents.

The 'mailto' URI Scheme: Improving Compatibility with IRIs
Martin Dürst, Larry Masinter, Jamie Zawinski (eds), IETF Internet Draft

A revised IETF Internet Draft has been published for the Standards Track specification The 'mailto' URI Scheme, intended to supersede and obsolete the IETF Proposed Standard Request for Comments #2368. This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368).

The 'mailto' URI scheme is used to identify resources that are reached using Internet mail. In its simplest form, a 'mailto' URI contains an Internet mail address. For interactions that require message headers or message bodies to be specified, the 'mailto' URI scheme also allows providing mail header fields and the message body.

This specification extends the previous scheme definition to also allow character data to be percent-encoded based on UTF-8 (IETF STD 63), which offers a better and more consistent way of dealing with non-ASCII characters for internationalization. This specification does not address the needs of the ongoing Email Address Internationalization effort; see RFC 4952. In particular, this specification does not include syntax for fallback addresses...

A 'mailto' URI designates an "internet resource", which is the mailbox specified in the address. When additional header fields are supplied, the resource designated is the same address, but with an additional profile for accessing the resource. While there are Internet resources that can only be accessed via electronic mail, the 'mailto' URI is not intended as a way of retrieving such objects automatically. The operation of how any URI scheme is resolved is not mandated by the URI specifications. In current practice, resolving URIs such as those in the 'http' URI scheme causes an immediate interaction between client software and a host running an interactive server. The 'mailto' URI has unusual semantics because resolving such a URI does not cause an immediate interaction with a server. Instead, the client creates a message to the designated address with the various header fields set as default..."

See also: IETF RFC 2368

Preservation Metadata: PREMIS in METS Toolbox
Priscilla Caplan, D-Lib Magazine

"Implementers of the PREMIS ['PREservation Metadata: Implementation Strategies'] Data Dictionary for Preservation Metadata now have a set of tools to support their PREMIS implementations in the PREMIS in METS Toolbox. The Toolbox works with standalone PREMIS documents and with PREMIS elements embedded within METS documents.

The Validate tool will validate a PREMIS document against the PREMIS schema and return a conformation message or list of errors. It will validate a METS document against the METS schema and also against set of rules for PREMIS in METS best practice encoded in Schematron (ISO/IEC 19757-3:2006). Best practice follows the Guidelines for Using PREMIS With METS for Exchange (September, 2008).

The Convert tool will take a PREMIS or METS document as input. Given a PREMIS document, it will generate an output METS document containing the PREMIS elements according to best practice. The user can specify whether to put all PREMIS elements in a single METS digiProvMD section, or distribute the elements into digiProvMD, rightsMD, and techMD sections. Given a METS document containing PREMIS elements, Convert will generate a stand-alone PREMIS document.

The Describe tool takes any digital file as input and generates its description in a PREMIS document. Describe invokes the DAITSS 2 Description Service which in turn uses DROID for format identification and JHOVE for characterization. General file metadata including format, file size, checksum, creator, create date, and inhibitors is supplied, as well as format-specific metadata for JPEG, JP2 and TIFF images (MIX), WAVE and AIFF (AES-X098B), ASCII, UTF8 and XML (TextMD), and PDF (DocMD). The PREMIS document generated by Describe can then be submitted to the Convert tool to create a METS document if desired..."

See also: the PREMIS web site

Smart Credit Cards Finally Arrive in U.S.
Jaikumar Vijayan, ComputerWorld

"Credit cards featuring smartcard technology have been standard fare around the world for several years now — but not in the U.S., where financial institutions have continued using cards based on less-secure magnetic stripe technology.

That may finally be about to change. Last week, the United Nations Federal Credit Union (UNFCU) became the first financial institution in the U.S. to unveil plans to issue credit cards that comply with the Europay MasterCard Visa (EMV) smartcard standard. The credit union's new Platinum Visa EMV cards will be issued to about 5,000 of its most high-value customers and can be used anywhere EMV cards are accepted

Cards based on the EMV standard use an embedded microprocessor instead of a magnetic stripe to store cardholder data and all of the other information needed to use the card for a transaction. Many financial institutions that issue EMV Chip cards also require cardholders to enter a Personal Identification Number (PIN) as an added security measure when using the card.

Chip-and-PIN credit cards are considered to be significantly safer than cards with magnetic stripes, which has led to the widespread adoption of EMV smartcards across Europe and in several other countries...."

Android Surges Into Second Place
Keith Ward, Application Development Trends

"The open source Android smartphhone market just hit a milestone of sorts: it surpassed the iPhone in popularity, moving into the second overall spot behind industry leader RIM OS (BlackBerry). That's according to anaylst firm NPD, which tracks smartphone usage. Its Q1 2010 figures show RIM with 36 percent of the market, Android at 28 percent, and iPhone in third at 21 percent. Ross Rubin, executive director of industry analysis for NPD, said in a press release that marketing has been crucial in Android's rise. 'As in the past, carrier distribution and promotion have played a crucial role in determining smartphone market share. In order to compete with the iPhone, Verizon Wireless has expanded its buy-one-get-one offer beyond RIM devices to now include all of their smartphones'..."

Android is also available in far more phones and on more carriers than the single-phone, single-carrier iPhone. Verizon, for instance, lists three Android-based phones for sale on its Web site, with two more models — the HTC Droid Incredible and LG Ally — coming soon

From the announcement: "The Android operating system (OS) continued to shake up the U.S. mobile phone market in the first quarter (Q1) of 2010, moving past Apple to take the number-two position among smartphone operating systems, according to The NPD Group, a leading market research company. NPD's wireless market research reveals that based on unit sales to consumers last quarter the Android operating system moved into second position at 28 percent behind RIM's OS (36 percent) and ahead of Apple's OS (21 percent). ..

The continued popularity of messaging phones and smartphones resulted in slightly higher prices for all mobile phones, despite an overall drop in the number of mobile phones purchased in the first quarter. The average selling price for all mobile phones in Q1 reached $88, which is a 5 percent increase from Q1 2009. Smartphone unit prices, by comparison, averaged $151 in Q1 2010, which is a 3 percent decrease over the previous year..."

See also: the NPD Group announcement


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

Headlines

Sponsors