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

OASIS BPEL4People TC Releases Specifications for Public Review
W3C Internationalization Resource: Choosing a Language Tag
Discovering the Local Location Information Server (LIS)
Namespaces in XML 1.0 Third Edition Advanced to W3C Recommendation
IESG Last Call Review: Link Relations for Simple Version Navigation
W3C Last Call Public Review: Widget Access Request Policy
NIST Invites Review on Security Requirements for Cryptographic Modules
User Authentication: It Doesn't Belong In Your Application

OASIS BPEL4People TC Releases Specifications for Public Review
Luc Clément, Dieter König, Vinkesh Mehta (et al, eds), OASIS Public Review Drafts

Members of the OASIS WS-BPEL Extension for People (BPEL4People) Technical Committee have approved Committee Draft specifications for public review through February 13, 2010. This OASIS TC was chartered in January 2008 "to define (1) extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions, and (2) a model of human interactions that are service-enabled. In particular, the Technical Committee is defining the specification of a WS-BPEL extension enabling the definition of human interactions ("human tasks") as part of a WS-BPEL process, defining the specification of a model enabling the definition of human tasks that are exposed as Web services, and defining a programming interface enabling human task client applications to work with human tasks."

The Committee Draft of WS-BPEL Extension for People (BPEL4People) Specification Version 1.1 introduces "a BPEL extension to address human interactions in BPEL as a first-class citizen. It defines a new type of basic activity which uses human tasks as an implementation, and allows specifying tasks local to a process or use tasks defined outside of the process definition. This extension is based on the WS-HumanTask specification. Web Services Business Process Execution Language, version 2.0 (WS-BPEL 2.0 or BPEL for brevity) introduces a model for business processes based on Web services. A BPEL process orchestrates interactions among different Web services. The language encompasses features needed to describe complex control flows, including error handling and compensation behavior. In practice, however many business process scenarios require human interactions. A process definition should incorporate people as another type of participants, because humans may also take part in business processes and can influence the process execution."

The Committee Draft of Web Services: Human Task (WS-HumanTask) Specification Version 1.1 introduces "the definition of human tasks, including their properties, behavior and a set of operations used to manipulate human tasks. A coordination protocol is introduced in order to control autonomy and life cycle of service-enabled human tasks in an interoperable manner. 'Human tasks', or briefly tasks enable the integration of human beings in service-oriented applications. This document provides a notation, state diagram and API for human tasks, as well as a coordination protocol that allows interaction with human tasks in a more service-oriented fashion and at the same time controls tasks' autonomy. The document is called Web Services Human Task. Human tasks are services 'implemented' by people. They allow the integration of humans in service-oriented applications. A human task has two interfaces. One interface exposes the service offered by the task, like a translation service or an approval service. The second interface allows people to deal with tasks, for example to query for human tasks waiting for them, and to work on these tasks.

A human task has people assigned to it. These assignments define who should be allowed to play a certain role on that task. Human tasks might be assigned to people in a well-defined order. This includes assignments in a specific sequence and or parallel assignment to a set of people or any combination of both. Human tasks may also specify how task metadata should be rendered on different devices or applications making them portable and interoperable with different types of software. Human tasks can be defined to react to timeouts, triggering an appropriate escalation action. This also holds true for notifications. A notification is a special type of human task that allows the sending of information about noteworthy business events to people. Notifications are always one-way, i.e., they are delivered in a fire-and-forget manner: The sender pushes out notifications to people without waiting for these people to acknowledge their receipt..."

See also: WS-HumanTask

W3C Internationalization Resource: Choosing a Language Tag
Richard Ishida (ed), W3C Internationalization Resource

W3C announced the publication of an educational resource from the W3C Internationalization web site on Choosing a Language Tag. The Internationalization Core Working Group publishes information to help people understand and use international aspects of W3C technologies. The appearance of 'Tags for Identifying Languages' (IETF RFC 5646) earlier in 2009 added a new 'extended language' subtag to BCP 47, and around 7,000 new entries in the IANA Language Subtag Registry. This W3C article asks: 'Which language tag is right for me?', and 'How do I choose the language and other subtags I need?'

The article outlines the necessary decisions in a step-by-step fashion... All the subtags you will need to create a language tag are found in one place, the IANA Language Subtag Registry. The registry is a long text file, containing nearly 8,000 entries. The first (and often only) subtag in a language tag always designates a language. It is referred to in BCP 47 as the primary language subtag. We will use that term in this document to refer to the subtag that represents a language, to more clearly make the distinction from 'language tag', which refers to the whole thing. To find a primary-language subtag, search the page for the name of that language...

(1) Decision 1: The primary language subtag. You always start by choosing a primary language subtag, and often this is all you'll need for your language tag. (2) Decision 2: Extended language subtags. The BCP 47 specification allows for an additional, 3-letter subtag immediately after the initial primary language subtag. This is called an extended language subtag, abbreviated to extlang (3) Decision 3: Script subtags. Script subtags should only be used as part of a language tag when the script adds some useful distinguishing information to the tag. Usually this is because a language is written in more than one script or because the content has been transcribed into a script that is unusual to the language. (4) Decision 4: Region subtags. Region subtags associate the language subtag you have chosen with a particular region of the world. (5) Decision 5: Variant subtags for use when there is a need to distinguish this language tag from another similar one in the context in which your content is used. (6) Decision 6: Private Use subtags. Private-use subtags do not appear in the subtag registry, and are chosen and maintained by private agreement between the parties that use them..."

Discovering the Local Location Information Server (LIS)
Martin Thomson and James Winterbottom (eds), IETF Internet Draft

Members of the IETF Geographic Location/Privacy (GEOPRIV) Working Group have released a revised version of the Standards Track I-D Discovering the Local Location Information Server (LIS). Discovery of the correct Location Information Server (LIS) in the local access network is necessary for devices that wish to acquire location information from the network. In this specification a method is described for the discovery of a LIS in the access network serving a device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process.

Discovery Procedure Overview: "DHCP ([RFC2131], [RFC3315]) is a commonly used mechanism for providing bootstrap configuration information allowing a device to operate in a specific network environment. The bulk of DHCP information is largely static; consisting of configuration information that does not change over the period that the device is attached to the network. Physical location information might change over this time, however the address of the LIS does not. Thus, DHCP is suitable for configuring a device with the address of a LIS... The product of this discovery process is an http: or https: URI, which identifies a LIS.

Each access network requires specific knowledge about topology. Therefore, it is important to discover the LIS that has the specific knowledge necessary to locate a device. That is, the LIS that serves the current access network. Automatic discovery is important where there is any chance of movement outside a single access network. Reliance on static configuration can lead to unexpected errors if a device moves between access networks..."

The IETF Geographic Location/Privacy (GEOPRIV) Working Group was created with realization that "many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications... The GEOPRIV working group is chartered to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group works with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols..."

Namespaces in XML 1.0 Third Edition Advanced to W3C Recommendation
Tim Bray, Dave Hollander (et al, eds), W3C Technical Report

Members of the W3C XML Core Working Group, as part of the W3C XML Activity, have published Namespaces in XML 1.0 (Third Edition) as a W3C Recommendation, superseding the Second Edition. Known implementations are documented in the Namespaces 1.1 implementation report, since all known Namespaces 1.1 implementations also support Namespaces 1.0. A test suite is also available via the XML Test Suite page. This third edition incorporates all known errata as of the publication date. This edition has been widely reviewed; only minor editorial changes have been made since the 6-August-2009 Proposed Edited Recommendation.

"XML namespaces provide a simple method for qualifying element and attribute names used in Extensible Markup Language documents by associating them with namespaces identified by URI references." In addition, XML namespaces are now commonly used to define 'spaces for names' of functions, properties, messages, and other collections of identifiers which share a common space.

Motivation and Summary: "We envision applications of Extensible Markup Language (XML) where a single XML document may contain elements and attributes (here referred to as a 'markup vocabulary') that are defined for and used by multiple software modules. One motivation for this is modularity: if such a markup vocabulary exists which is well-understood and for which there is useful software available, it is better to re-use this markup rather than re-invent it. Such documents, containing multiple markup vocabularies, pose problems of recognition and collision. Software modules need to be able to recognize the elements and attributes which they are designed to process, even in the face of "collisions" occurring when markup intended for some other software package uses the same element name or attribute name.

These considerations require that document constructs should have names constructed so as to avoid clashes between names from different markup vocabularies. This specification describes a mechanism, XML namespaces, which accomplishes this by assigning expanded names to elements and attributes..."

See also: Namespaces in XML

IESG Last Call Review: Link Relations for Simple Version Navigation
Al Brown, Geoffrey Clemm, Julian Reschke (eds), IETF Internet Draft

The Internet Engineering Steering Group (IESG) announced the publication of a Last Call review for IETF Internet Draft Link Relations for Simple Version Navigation. IESG received a request to consider this specification as an IETF Informational RFC, and plans to make a decision in the next few weeks; IESG therefore solicits final comments on this action, inviting submission of substantive comments by 2010-01-11.

The specification defines link relations that may be used on a resource that exists in a system that supports versioning to navigate among the different resources available, such as past versions... When a resource is put under version control, it becomes a 'versioned resource'. Many servers protect versioned resources from modifications by considering them 'checked in', and by requiring a 'checkout' operation before modification, and a 'checkin' operation to get back to the 'checked-in' state. Other servers allow modification, in which case the checkout/checkin operation may happen implicitly. A 'version history' resource is a resource that contains all the versions of a particular versioned resource...

When a versioned resource is checked out and then subsequently checked in, the version that was checked out becomes a 'predecessor' of the version created by the checkin. A client can specify multiple predecessors for a new version if the new version is logically a merge of those predecessors. The inverse of the predecessor relation is the 'successor' relation. Therefore, if X is a predecessor of Y, then Y is a successor of X... A 'working copy' is a resource at a server-defined URL that can be used to create a new version of a versioned resource... A 'checkout' is an operation on a versioned resource that creates a working copy, or changes the versioned resource to be a working- copy as well ('in-place versioning').... Checkin A 'checkin' is an operation on a working copy that creates a new version of its corresponding versioned resource...

The following link relations are defined in this I-D: (1) version-history: when included on a versioned resource, this link points to a resource containing the version history for this resource. (2) latest-version: when included on a versioned resource, this link points to a resource containing the latest (e.g., current) version. The latest version is defined by the system. For linear versioning systems, this is probably the latest version by timestamp. For systems that support branching, there will be multiple latest versions, one for each branch in the version history. Some systems may allow multiple of these link relations. (3) working-copy: when included on a versioned resource, this link points to a working copy for this resource. Some systems may allow multiple of these link relations. (4) working-copy-of: when included on a working copy, this link points to the versioned resource from which this working copy was obtained. (5) predecessor-version: when included on a versioned resource, this link points to a resource containing the predecessor version in the version history. Some systems may allow multiple of these link relations in the case of a multiple branches merging. (6) successor-version: when included on a versioned resource, this link points to a resource containing the successor version in the version history. Some systems may allow multiple of these link relations in order to support branching..."

See also: Atom references

W3C Last Call Public Review: Widget Access Request Policy
Robin Berjon (ed), W3C Technical Report

W3C's Web Applications Working Group has published a Last Call Working Draft of the Widget Access Request Policy specification, inviting public comment through January 13, 2010. The W3C Web Applications (WebApps) Working Group, a merger of the WebAPI and WAF Working Groups, was chartered to develop standard APIs for client-side Web Application development.

"A 'Widget' is an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine or mobile device. Typical examples of widgets include clocks, CPU gauges, sticky notes, battery-life indicators, games, and widgets that make use of Web services, like weather forecasters, news readers, e-mail checkers, photo albums and currency converters.

Summary: "User agents running widgets are expected to provide access to potentially sensitive APIs (phone book, calendar, file system, etc.) that expose data which should not be exposed without the user's consent.

The purpose of this specification is to define the security model for network interactions from within a widget that has access to sensitive information. It provides means for a widget to declare its intent to access specific network resources so that a policy may control it, viz., a method for widget authors to request that the user agent grant access to certain network resources or sets thereof..."

W3C is creating a "Widget family of specifications, with updated public drafts of the following documents: Widgets 1.0: Requirements, Widgets 1.0: Packaging and Configuration, Widgets 1.0: URI Scheme, Widgets 1.0: APIs and Events, Widgets 1.0: Access Requests Policy (WARP), and Widgets 1.0: Digital Signatures..."

NIST Invites Review on Security Requirements for Cryptographic Modules
Staff, U.S. National Institute of Standards and Technology Announcement

"The Revised Draft FIPS 140-3 is the second public draft of NIST's proposed revision of FIPS 140-2. The Revised Draft was developed using the comments received on the first public draft, which was posted for public review and comment on July 13, 2007, and the FIPS 140-3 Software Security Workshop held on March 18, 2008...

While the 2007 Draft proposed 5 levels of security, the Revised Draft FIPS 140-3 reverts to 4 levels of security as currently specified in FIPS 140-2. In contrast to the 2007 Draft, the Revised Draft also reintroduces the notion of firmware cryptographic module and defines the security requirements for it, limits the overall security level for software cryptographic modules to Security Level 2, and removes the formal model requirement at Security Level 4. Differences with the current FIPS 140-2 standard include limiting the overall security level for software cryptographic modules to Security Level 2, requirements for mitigation of non-invasive attacks at higher security levels, elimination of the requirement for formal modeling at Security Level 4, modified conditions for pre-operational/power-on self-tests, and strengthened integrity testing.

All comments to the Revised Draft FIPS 140-3 must be received on or before March 11, 2010; please use the template provided..."

User Authentication: It Doesn't Belong In Your Application
Kyle Austin, DDJ

"When building Web-based app, you've got a thousand design and implementation decisions to make — decisions that affect the usability and performance of your application, as well as its key functionality. Unfortunately, user authentication is typically the last thing you spend design cycles on. Just do what you've always done—create a user database with accounts and passwords, and maybe hash the passwords for good measure. That approach doesn't work anymore. The online world is a complex place, and your application doesn't operate in isolation. The problem isn't so much one of technology as it is your users themselves. With dozens of accounts and passwords to manage, what do people do? They share them between applications. This means that even if your password file isn't compromised, attackers can still find ways into your data. And whether or not it's your fault, it's always your problem... The best illustration of this is the recent concentrated password attack on accounts belonging to Twitter employees... Identity Federation lets you leave all of these authentication issues to a third party (an Identity Provider) that builds their business on managing authentication. You can pick one or more identity providers to 'trust' with your users. You then focus on your core application, and let them authenticate your users for you... OpenID is a free, decentralized system for implementing a single digital identity online. Today, it is used mostly in the consumer space, and is being adopted by retail and community sites. Google, Yahoo and AOL can all serve as OpenID identity providers. SAML (Security Assertion Markup Language) is more widely used in business applications. Google Apps and Salesforce, for example, both support SAML-based single sign-on. And Microsoft's Active Directory Federation Standard (ADFS) supports SAML. Whether you use OpenID or SAML, the process is similar. Your application exchanges identity assertions with other applications, typically trusted identity providers or partners. The Identity Provider (IdP) authenticates the user. Your application is a 'service provider' or identity consumer (the terminology varies with the protocol). It consumes or accepts the identity assertions of the provider. Your application only needs to maintain the list of the providers or partners that you trust when it comes to user identity..."

See also: OpenID


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

Headlines

Sponsors