This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com
- State Chart XML (SCXML): State Machine Notation for Control Abstraction
- Microsoft Offers Free Repository for Agency Data
- Connecting to the Cloud: Realize the Hybrid Cloud Model
- Draft Guidelines Issued for Using SCAP to Automate Security Validation
- W3C Publishes Four XHTML Documents as Proposed Edited Recommendations
- Microsoft Releases Geneva Beta 2 for Claims-Based Identity
- Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
State Chart XML (SCXML): State Machine Notation for Control Abstraction
Jim Barnett, Rahul Akolkar, RJ Auburn, Michael Bodell, (et al., eds), W3C Technical Report
W3C announced that the Voice Browser Working Group has published an updated Working Draft for State Chart XML (SCXML): State Machine Notation for Control Abstraction. SCXML is a general-purpose event-based state machine language that may be used in a number of ways, including as a high-level dialog language controlling VoiceXML 3.0's encapsulated speech modules, or as a multimodal control language in the MultiModal Interaction framework. The main differences from the previous draft are: (1) a revision of the send and invoke elements, and (2) the introduction of Event I/O processors to support them.
From the Overview: "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. The goal of this document is to combine Harel semantics with an XML syntax that is a logical extension of CCXML's state and event notation. 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... SCXML can be used (1) as a general process control language in other contexts not involving speech processing; (2) 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. (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...
See also: the W3C Voice Browser Activity
Microsoft Offers Free Repository for Agency Data
Joab Jackson, Government Computer News
Connecting to the Cloud: Realize the Hybrid Cloud Model
Mark O'Neill, IBM developerWorks
This article is Part 2 of a three-part series on connecting to the cloud. To determine the best solution for creating a hybrid cloud application, Part 1 examined some of the offerings from the major cloud platform vendors. In this article, Part 2 of the series, we implement the hybrid cloud application, which combines local application components with cloud computing. The application makes use of a JMS queue locally as well as an SQS queue in the cloud, combining the two in a single hybrid application. The example application, called HybridCloud, takes data from a JMS queue and passes the data up to an Amazon SQS queue, which is hosted in the Amazon cloud. Once in the Amazon SQS queue, the data can be pulled down by another application with the rights to that queue. We use Java code to connect a local application to a cloud computing environment. This is an ideal solution for developers, but as part of an application, the connection to the Amazon cloud computing service does not come under the control of a network operations team, who might monitor usage, traffic, and availability. Additionally, any change to the cloud computing connection involves a code change. Although it is outside the scope of this article, it's possible to achieve the same connection between a local JMS queue and the Amazon SQS cloud service using a network infrastructure, that places the connection under the control of network operations staff. To connect a local application component, such as a JMS queue, to the cloud, requires an XML gateway that includes cloud computing connectors. The task of connecting a JMS queue to an Amazon SQS queue involves dragging-and-dropping connection filters together, so data is pulled from the JMS Queue and then trafficked to the Amazon cloud service. A useful analogy is the familiar cable TV box. This box connects local infrastructure (televisions) to the cloud (the cable TV operator). An XML gateway provides the role of the local cable box. In addition to providing the connection to the cloud services, it also provides monitoring and security for that connection...
See also: series article Part 1
Draft Guidelines Issued for Using SCAP to Automate Security Validation
William Jackson, Government Computer News
"The U.S. National Institute of Standards and Technology has released a draft of its guidelines for using the Security Content Automation Protocol (SCAP) for checking and validating security settings on IT systems. SCAP is a NIST specification for expressing and manipulating security data in standardized ways. It can enumerate product names and vulnerabilities, including software flaws and configuration issues, identify the presence of vulnerabilities and assign severity scores to software flaws." Edited by Matthew Barrett, Chris Johnson, Peter Mell, Stephen Quinn, Karen Scarfone, the Draft NIST Special Publication 800-117 (Guide to Adopting and Using the Security Content Automation Protocol (SCAP)) defines SCAP and the component specifications that comprise it. The Guide "describes common uses of SCAP and makes recommendations for SCAP users and provides insights to IT product and service vendors about adopting SCAP in their offerings.
SCAP has two major elements. First, it is a protocol: a suite of six open specifications that standardize the format and nomenclature by which security software communicates information about software flaws and security configurations. Each specification is also known as an SCAP component. Second, SCAP includes software flaw and security configuration standardized reference data, also known as SCAP content. SCAP has several uses, including automating checks for known vulnerabilities, automating the verification of security configuration settings, and generating reports that link low-level settings to high-level requirements. There are six principal components of the SCAP protocol. SCAP version 1.0 is comprised of particular versions of these components, as listed in draft NIST Interagency Report (NISTIR) 7511, Security Content Automation Protocol (SCAP) Version 1.0 Validation Program Test Requirements. The components are grouped by type: enumerations, vulnerability measurement and scoring, and expression and checking languages. The enumerations group has nomenclatures and dictionaries for security and product-related information. The vulnerability measurement and scoring group has specifications for measuring the characteristics of vulnerabilities and generating scores based on those characteristics. The expression and checking languages group has Extensible Markup Language (XML) schemas for specifying checklists, generating checklist reports, and specifying the low-level testing procedures used by the checklists...
SCAP content — reference data — is available from multiple sources. For example, NVD hosts a dictionary of CPE entries and information on CVE entries, while the MITRE Corporation hosts an OVAL database and maintains a list of CCE entries. Each of the six SCAP components offers a unique function and is used independently, but greater benefits can be achieved by using the components together. For example, the ability to express CCEs according to CPEs in an XCCDF format comprises the building blocks for SCAP-expressed checklists. In other words, SCAP-expressed checklists use a standardized language (XCCDF) to express what platform is being discussed (CPE) and what security settings (CCE) should be addressed..."
W3C Publishes Four XHTML Documents as Proposed Edited Recommendations
Shane McCarron, Masayasu Ishikawa (et al. eds), W3C Technical Reports
Members of the the W3C XHTML2 Working Group have published four Proposed Edited Recommendations. This Working Group was chartered to continue the XHTML2 work from the previous HTML WG charter to produce the accessible, semantic, next-generation XHTML2. This includes producing a new version of XML Events, producing a new Access Key module in cooperation with the WAI Working Groups, and finishing work on XHTML 2.0, which combines all the new modules into a single profile.
(1) XHTML 1.1 - Module-based XHTML - Second Edition serves as the basis for future extended XHTML 'family' document types. It defines an XHTML document type that is based upon the module framework and modules defined in XHTML Modularization. This document type is most similar to XHTML 1.0 Strict, built using XHTML Modules. This means that many facilities available in other XHTML Family document types (e.g., XHTML Frames) are not available in this document type. These other facilities are available through modules defined in XHTML Modularization, and document authors are free to define document types based upon XHTML 1.1 that use these facilities... This draft reflects clarifications and corrections as a result of many years of use by the community. It also includes an XML Schema implementation of the language, and integrates the lang attribute to increase compatibility with User Agents and Assistive Technologies.
(2) XHTML Basic 1.1 - Second Edition includes the minimal set of modules required to be an XHTML host language document type, and in addition it includes images, forms, basic tables, and object support. It is designed for Web clients that do not support the full set of XHTML features; for example, Web clients such as mobile phones, PDAs, pagers, and settop boxes. The document type is rich enough for content authoring. XHTML Basic is designed as a common base that may be extended. The goal of XHTML Basic is to serve as a common language supported by various kinds of user agents.
(3) XHTML-Print - Second Edition is a member of the family of XHTML languages defined by the Modularization of XHTML. It is designed to be appropriate for printing from mobile devices to low-cost printers that might not have a full-page buffer and that generally print from top-to-bottom and left-to-right with the paper in a portrait orientation. XHTML-Print is also targeted at printing in environments where it is not feasible or desirable to install a printer-specific driver and where some variability in the formatting of the output is acceptable.
(4) XHTML 1.0 The Extensible HyperText Markup Language (Third Edition) - A Reformulation of HTML 4 in XML 1.0 defines the Third Edition of XHTML 1.0, a reformulation of HTML 4 as an XML 1.0 application, and three DTDs corresponding to the ones defined by HTML 4. The semantics of the elements and their attributes are defined in the W3C Recommendation for HTML 4. These semantics provide the foundation for future extensibility of XHTML. Compatibility with existing HTML user agents is possible by following a small set of guidelines ("XHTML Media Types").
See also: the W3C news item
Microsoft Releases Geneva Beta 2 for Claims-Based Identity
Staff, Microsoft Forefront Team Blog
"Microsoft has now released Beta 2 of 'Geneva,' the open platform that dramatically simplifies user access and secure collaboration across organizational boundaries. Geneva is part of our Business Ready Security strategy. It supports the strategy's tenets of 'integrating and extending security across the enterprise' and helping to 'protect everywhere, access anywhere' through interoperability with heterogeneous environments and third party solutions...With beta 2 we're announcing interoperability between Geneva and identity & access solutions from leading partners, via the SAML 2.0 and WS-Federation standards. Interoperable partner solutions include CA Federation Manager and CA SiteMinder, Novell Access Manager, SAP NetWeaver and Sun's OpenSSO Enterprise and Fedlet software. We are issuing interoperability white papers with these partners and at TechEd this week SAP is presenting on their work with Geneva.
With this release, Geneva addresses a number of important customer challenges: (1) Implementing cross-organization single sign on: Connecting people and applications with those of other business units, customers, and partners is typically costly, risky and a drag on collaboration. Through identity federation in Geneva, IT departments can facilitate collaboration without managing extra user accounts and passwords, or compromising security. (2) Accessing hosted and cloud services: Geneva extends Active Directory authentication and single sign-on to cloud-based services, hosted by Microsoft or others, so IT can securely realize the flexibility and cost savings gains of hosted applications. (3) Developing identity-aware applications: With the 'Geneva Framework, a developer can apply pre-built application authentication, attribute lookup and authorization for richer, more secure applications—without becoming a security expert. (4) Simplifying access management: IT organizations have fewer resources to manage more and more applications that have many users, run on multiple platforms and require more complex forms of security. 'Geneva' empowers IT to centrally manage access to applications of various types and apply security policy in a standard way across the enterprise... The new beta introduces new features, such as the seamless integration with Visual Studio, which make even easier for developers to take advantage of identity capabilities without being exposed to unnecessary complexity; or the new claims transformation language, which has no counterpart in competitor's products and gives unprecedented expressive power to system administrators."
See also: the earlier Geneva news story
Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
Russell Housley and Morris Dworkin (eds), IETF Last Call Internet Draft
The Internet Engineering Steering Group (IESG) announced that it has received a Last Call request to consider Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm as an IETF Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. This specification defines a padding convention for use with the AES Key Wrap algorithm specified in IETF RFC 3394 ("Advanced Encryption Standard (AES) Key Wrap Algorithm"). This convention eliminates the requirement that the length of the key to be wrapped is a multiple of 64 bits, allowing a key of any practical length to be wrapped.
From the document 'Introduction': "Management of cryptographic keys often leads to situations where a symmetric key is used to encrypt and integrity protect another key, which can be either a symmetric key or an asymmetric key. The operation is often called key wrapping. This document specifies an extension of the Advanced Encryption Standard (AES) Key Wrap algorithm. Without this extension, the input to the AES Key Wrap algorithm, called the key data, must be a sequence of two or more 64-bit blocks. The AES Key Wrap with Padding algorithm can be used to wrap a key of any practical size with an AES key. The AES key-encryption key (KEK) must be 128, 192, or 256 bits. The input key data may be as short as 9 octets, which will result in an output of two 64-bit blocks or 16 octets. Although the AES Key Wrap algorithm does not place a maximum bound on the size of the key data that can be wrapped, this extension does so... The key wrapping technique specified in this document requires the length of the key data to be at least nine octets because a single application of the AES codebook is sufficient to protect up to eight octets of key data. In particular, if the key data consists of eight or fewer octets, then a 64-bit integrity check value could be prepended to the key data to form a single 128-bit block. For example, the integrity check value could consist of a fixed seven octet value followed by a single octet length value. The wrapping and unwrapping processes employing such an integrity check value and a single AES codebook operation could be defined analogous to those in Section 4 if there is a need to wrap keys that are smaller than nine octets.
XML Daily Newslink and Cover Pages sponsored by:
|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: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/