Cover Pages: XML Daily Newslink: Thursday, 14 January 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:
Sun Microsystems, Inc. http://sun.com

Headlines

W3C Working Draft: Programmable HTTP Caching and Serving
A SASL Mechanism for SAML
A Step Toward Better Cloud Security: Searchable Encryption
WebCGM 2.1 Advanced to W3C Proposed Recommendation
Being RESTful With SugarCRM

W3C Working Draft: Programmable HTTP Caching and Serving
Nikunj Mehta (ed), Technical Report

Members of the W3C Web Applications Working Group have published a Working Draft for Programmable HTTP Caching and Serving. This document defines APIs for off-line serving of requests to HTTP resources using static and dynamic responses. It extends the function of application caches defined in HTML5.

Background: "The existing cache manifest defined in HTML5 statically identifies cached resources to be stored in an application cache. The API introduced in this document extends the application cache by allowing applications to programmatically add other resources to the cache which can then be served by the user agent when that resource is requested. This API also extends the application cache to enable applications to programmatically generate responses to requests for resources that have been added to the application cache. As a result, the application cache can now be used to satisfy unsafe HTTP methods such as PUT and POST. Using this application cache extension, applications can obtain locally cached data or data produced locally by JavaScript servers and perform requests on resources that can be served whether or not the user agent is connected to a remote server. Applications can then save and replay locally satisfied requests to the server when it is reconnected, thus enabling responsive and robust Web applications in the presence of low connectivity conditions...

This specification does not require a new programming model for Web applications as application caches can be configured to be transparently pressed into action by the user agent, depending on system conditions. Such applications can seamlessly switch between on-line and off-line operation without needing explicit user action. This also means that existing applications can be used unchanged in many cases once the application cache is configured. Applications only need to be altered to use APIs specified in this document if they require more complex synchronization..."

The W3C Rich Web Clients Activity contains the work within W3C on Web Applications: "With the ubiquity of Web browsers and Web document formats across a range of platforms and devices, many developers are using the Web as an application environment. Examples of applications built on rich Web clients include reservation systems, online shopping or auction sites, games, multimedia applications, calendars, maps, chat applications, weather displays, clocks, interactive design applications, stock tickers, office document and spreadsheet applications, currency converters, and data entry/display systems... The work of the Web Applications (WebApps) WG covers both APIs and formats. APIs are the assorted scripting methods that are used to build rich Web applications, mashups, Web 2.0 sites. Standardizing APIs improves interoperability and reduces site development costs. Formats covers certain markup languages, including Widgets for deploying small Web applications outside the browser, and XBL for skinning applications..."

A SASL Mechanism for SAML
Klaas Wierenga and Eliot Lear (eds), IETF Internet Draft

An initial level -00 Standards Track IETF Internet Draft has been published for the specification A SASL Mechanism for SAML. The new memo specifies a SASL mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL.

Details: "Security Assertion Markup Language (SAML) is a multi-party protocol (or rather set of protocols) that provides a means for a user to offer identity assertions and other attributes to a relying party (RP) via the help of an identity provider (IdP).

Simple Authentication and Security Layer (SASL) is defined in IETF standards Track RFC #4422, edited by Alexey Melnikov and Kurt D. Zeilenga. The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.

SASL is used by application protocols like IMAP, POP and XMPP. The effect is to make modular authentication, so that newer authentication mechanisms can be added as needed. This memo specifies just such a mechanism. As currently envisioned, this mechanism is to allow the interworking between SASL and SAML in order to assert identity and other attributes to relying parties. As such, while servers (as relying parties) will advertise SASL mechanisms (including SAML), clients will select the SAML SASL mechanism as their SASL mechanism of choice. The SAML mechanism described in this memo aims to re-use the available SAML deployment to a maximum extent and therefore does not establish a separate authentication, integrity and confidentiality mechanism. It is anticipated that existing security layers, such as Transport Layer Security (TLS), will continued to be used..."

A Step Toward Better Cloud Security: Searchable Encryption
Abel Avram, InfoQueue

In a whitepaper entitled Cryptographic Cloud Storage, Seny Kamara and Kristin Lauter from the Microsoft Research Cryptography Group, propose a 'virtual private storage service' offered by public clouds using new cryptographic techniques...

Kamara and Lauter propose a virtual private storage service which would satisfy the following requirements: (1)confidentiality: the cloud storage provider does not learn any information about customer data' (2) integrity: any unauthorized modification of customer data by the cloud storage provider can be detected by the customer; (3) non- repudiation: any access to customer data is logged, while retaining the main benefits of a public storage service; (4) availability: customer data is accessible from any machine and at all times; (5) reliability: customer data is reliably backed up (6)efficient retrieval: data retrieval times are comparable to a public cloud storage service; (7) data sharing: customers can share their data with trusted parties.

Most of the requirements are obtained by encrypting the documents stored in the cloud, but encryption makes it very hard to search through such documents or to collaborate in real time editing. The Cryptographic Cloud Storage whitepaper proposes an architecture for a cryptographic storage service that would solve the security problems of back-ups, archival, health record systems, secure data exchange and e-discovery...

The authors now describe, at a high level, a possible architecture for a cryptographic storage service. At its core, the architecture consists of three components: a data processor (DP), that processes data before it is sent to the cloud; a data verifier (DV), that checks whether the data in the cloud has been tampered with; and a token generator (TG), that generates tokens which enable the cloud storage provider to retrieve segments of customer data. We describe designs for both consumer and enterprise scenarios..."

See also: the Microsoft White Paper

WebCGM 2.1 Advanced to W3C Proposed Recommendation
Benoit Bezaire and Lofton Henderson (eds), W3C Technical Report

The W3C WebCGM Working Group has published a Proposed Recommendation for the WebCGM 2.1 specification. Computer Graphics Metafile (CGM) is an ISO standard, defined by ISO/IEC 8632:1999, for the interchange of 2D vector and mixed vector/raster graphics. WebCGM is a profile of CGM, which adds Web linking and is optimized for Web applications in technical illustration, electronic documentation, geophysical data visualization, and similar fields.

WebCGM 2.1, refines and completes the features of the major WebCGM 2.0 release. WebCGM 2.0 added a DOM (API) specification for programmatic access to WebCGM objects, a specification of an XML Companion File (XCF) architecture, and extended the graphical and intelligent content of WebCGM 1.0.

The design criteria for WebCGM aim to balance graphical expressive power on the one hand, versus simplicity and implementability on the other. A small but powerful set of standardized metadata elements supports the functionalities of hyperlinking and document navigation, picture structuring and layering, and enabling search and query of WebCGM picture content...

WebCGM 2.1 is related to the previous W3C work on WebCGM 1.0 and 2.0. WebCGM 2.0 was simultaneously published by W3C as a Recommendation and by OASIS as an OASIS Standard. The two versions are identical in technical content, differing only in the formatting and presentation conventions of the two organizations. It is agreed that WebCGM 2.1 will be progressed by the same collaborative process and will result in technically a identical Recommendation and OASIS Standard..."

Being RESTful With SugarCRM
John Mertic, IBM developerWorks

"REST (REpresentational State Transfer), is designed to be a very mean, lean Web services protocol. It came into being as a response to heavyweight Web services protocols such as SOAP and XML-RPC, which rely on a predefined messaging format and methods to pass them back and forth between servers and clients. REST, on the other hand, specifies no such limitations; you can use any message format that you like (whether it be JSON, XML, HTML, serialized data, or even straight text), and operates on the standard HTTP verbs of GET, DELETE, and POST for its operations. The rules that exist for REST client/server interactions can be completely defined by the application requirements. So if you define a REST interface that is intended to be consumed by a JavaScript client, you probably want to have the data returned in a JSON format, while if you intend for the data to be consumed by a PHP client, then perhaps serialized data or XML is a better choice. Each REST Web services call is just a simple HTTP request, using one of the standard HTTP verbs...

SugarCRM is the world's leading open source Customer Relationship Management (CRM) software provider, with over 5,000 customers and 500,000 downloads of the SugarCRM application all around the world. In December 2009, SugarCRM released version 5.5 of the application suite, which completely revitalized the Web Services platform. The changes include a faster, easier-to-use API, the ability to easily extend the API that is presented to a Web service client, and the addition of REST support.

In this article, we take a look at what REST is and how to use the REST support in the Web Services API to interact with a SugarCRM instance. SugarCRM comes with the Web services interface ready to go out of the box... Calls are made using POST requests to this URL, passing the needed arguments to the Web services call as POST parameters. For each interaction with the Web service, the client first must authenticate with the service using the login method call... This article looks at some examples that took advantage of the REST interface to the Sugar Web services framework. It shows how to add a new record to a module, and then how to modify that record. You also see how to add multiple records in one method call, saving the overhead of making several remote server calls in a row. Lastly, you see how to relate two different records together using the 'set_relationship' method of the Web services framework..."


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

Headlines

Sponsors