Cover Pages: XML Daily Newslink: Thursday, 18 March 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

Summary of Content Management Interoperability Services (CMIS) 1.0
W3C Charters New Web Fonts Working Group in the Fonts Activity
DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
Let Stormy Session on Cloud Standards Be Your Guide
NIST Draft on Key History for Personal Identity Verification (PIV) Cards
Policies and Rules for Improving Business Agility

Summary of Content Management Interoperability Services (CMIS) 1.0
David Choy (ed), OASIS CMIS TC Overview Document

"To mitigate the 'content silo' problem, the OASIS CMIS specifies an interoperability interface for content management systems so that generic applications can be developed that can access any CMIS-compliant repository. CMIS is a protocol-layer interface. But it is not singularly defined for a specific network protocol. The CMIS specification contains a domain model and a set of protocol bindings. For Version 1.0, two protocol bindings are defined: a WSDL-based Web Services binding (service-oriented), and a RESTful Atom Publishing Protocol binding (resource-oriented). The CMIS interface is designed to be layered on top of existing content management systems and their existing programmatic interfaces...

Four kinds of objects are defined: Document, Folder, Relationship, and Policy. They are defined as four separate root types in the type hierarchy, without imposing any affinity among them to allow maximum compliance. A repository may further define subtypes of these root types in support of specific applications. A subtype inherits property definitions from its supertype and may have additional property definitions of its own. Basic CRUD services (Create, Retrieve, Update, Delete) are provided for these objects and for content stream. In addition, a query service is provided for finding objects.

(1) A Document object represents an information asset managed by the repository. It may have a content stream, can be versioned, and is queryable. A Document may be filed in zero or more Folders... (2) A Document object represents an information asset managed by the repository. It may have a content stream, can be versioned, and is queryable. A Document may be filed in zero or more Folders... (3) A Relationship object represents a binary, peer-to-peer, directional relationship between two other objects; services are provided for navigation through Relationships... (4) A Policy object represents an administrative policy that can be applied to, or removed from, another object.

For the query service, CMIS supports a type-based, structured query language and leverages the SQL language. Specifically, a relational view is implicitly defined on top of the CMIS data model: a virtual table corresponding to each object type, and a table column corresponding to each property of an object type... CMIS provides an ACL-based access control capability, allowing an application to get, set, or alter simple access control rules for an object. An application may use or request either repository-specific permissions or CMIS-defined permissions... To validate the specification, a number of CMIS TC members have built prototypes, either to provide or to consume CMIS services, and tested interoperability between different vendor implementations..."

W3C Charters New Web Fonts Working Group in the Fonts Activity
Staff, W3C Announcement

W3C has created a new public group 'Web Fonts Working Group' as part of the W3C Fonts Activity. The initial Chair is Vladimir Levantovsky of Monotype Imaging. The mission of the Web Fonts Working Group is to develop specifications that allow the interoperable deployment of downloadable fonts on the Web. Existing specifications (CSS3 Fonts, SVG) explain how to describe and link to fonts, so the main focus will be the standardisation of font formats suited to the task, and a specification defining conformance (for fonts, authoring tools, viewers ...) covering all the technology required for WebFonts.

As the relevant specifications are all implemented, and either standardised (OpenType by ISO/IEC 14496-22:2009, SVG by the SVG 1.1 Recommendation) or mature (WOFF, EOT, CSS3 Fonts) the group would be chartered to only make the minimal changes needed for interoperability and standardisation. In addition, the provision of interoperable font formats would allow the testing of CSS3 Fonts, speeding it to Recommendation status.

One Recommendation-Track Deliverable (candidate) is the WOFF File Format specification. This document specifies a simple compressed file format for fonts, designed primarily for use on the web. The WOFF format is directly based on the table-based sfnt structure used in TrueType, OpenType, and Open Font Format fonts, which are collectively referred to as sfnt-based fonts. A WOFF font file is simply a repackaged version of a sfnt-based font in compressed form. The format also allows font metadata and private-use data to be included separately from the font data. WOFF encoding tools convert an existing sfnt-based font into a WOFF formatted file, and user agents restore the original sfnt-based font data for use with a webpage.

A WebFont conformance specification is also expected. It will reference the font formats in existing use (OpenType, WOFF, SVG, and EOT), the font referencing and linking specifications (in both CSS and XML serialisations), access policies such as same-origin and CORS, and define which linking mechanisms, policies and formats are required for compliance. WOFF will be the required format for compliance, the others being optional. The Working Group will decide whether to make the formats and linking mechanisms normative references or, on the other hand, produce a document citable by other specifications (CSS3 Fonts, XSL, SVG) when claiming conformance..."

See also: Fonts on the Web

DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
Tony Hansen, Ellen Siegel, Phillip Hallam-Baker, Dave Crocker; IETF Internet Draft

The Internet Engineering Steering Group (IESG) announced the approval of DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations as an IETF Informational RFC. The RFC was produced by members of the IETF Domain Keys Identified Mail (DKIM) Working Group. The document provides implementation, deployment, operational and migration considerations for DKIM. There are several areas where the document could provide more guidance, but the WG decided that more field experience is needed before we know what the guidance should be. Document Quality: This document gives guidance on implementation based on experience of participants and vendors who have already implemented the DKIM protocols. The document has been well reviewed by participants with implementation/ deployment experience. The document shepherd is Barry Leiba, and the responsible area director is Pasi Eronen.

DomainKeys, as specified in RFC 4871 and updated in RFC 5672, allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message contents.

DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational and migration considerations for DKIM. It presents Using DKIM as Part of Trust Assessment; DKIM Key Generation, Storage, and Management; Taxonomy of Signatures; Example Usage Scenarios; Usage Considerations.

DKIM participates in a trust-oriented enhancement to the Internet's email service, to facilitate message handling decisions, such as for delivery and for content display. Trust-oriented message handling has substantial differences from the more established approaches that consider messages in terms of risk and abuse. With trust, there is a collaborative exchange between a willing participant along the sending path and a willing participant at a recipient site. In contrast, the risk model entails independent, unilateral action by the recipient site, in the face of a potentially unknown, hostile and deceptive sender. This translates into a very basic technical difference: In the face of unilateral action by the recipient and even antagonistic efforts by the sender, risk-oriented mechanisms are be based on heuristics, that is, on guessing...

Let Stormy Session on Cloud Standards Be Your Guide
Charles Babcock, InformationWeek

"A panel Wednesday [2010-03-17] at the Cloud Connect show in Santa Clara, California to talk about where cloud standards are going did not go as planned. Whatever the script, it was as if the audience had come prepared to present its point of view, and the panel members were forced to listen. The topic, Where Standards Are Going' is both an open ended question and a provocation to entrepreneurs, vendors and established interests at a cloud conference... Speaking from unfettered, entrepreneurial point of view, [one member of the audience asserted]: 'Standards bodies are a solution in search of a problem. The people on standards bodies are in danger of speaking in an echo chamber. After a while, all they can hear is themselves'...

The standards defenders on the panel certainly got an earful. They included: William Vambenepe, a native of France and software architect for Oracle; Winston Bumpus, director of standards at VMware and president of the DMTF, formerly known as the Distributed Management Task Force; Archie Reed, distinguished technologist at HP, director of HP cloud security strategy and member of the standards advocating Cloud Security Alliance; and Krishna Sankar, distinguished engineer at Cisco Systems and co-chair of the DMTF's Open Cloud Standards Incubator, set up to generate informational specifications and create a well-defined semantics for enterprise-to-cloud operations.

The HP representative did not play an outspoken role in this debate, but HP has rarely been a tom-tom beating, look-at-me company. After the session Reed said HP is a supporter of both defacto and dejure standards and thrives as a company by understanding when following standards is in the customer's best interest. While there was anti-standards sentiment in the room, even today's dominant cloud company may find itself ignoring a well received standard for cloud computing at its own peril, he warned. For example, he's a member of the Cloud Security Alliance and no one needs to advise him that security is a big concern in cloud computing. Yet today's security standards, such as PCI, were defined for an era as different from cloud computing as armored cars are from SWIFT electronic fund transfers. The alliance may play a role in getting security standard writers to update their standards for the cloud environment. NIST will play a role, perhaps in illustrating a new way to implement security in the cloud...

Many left the Cloud Connect standards session believing the picture was more muddied at the end than when it began. But Krishna Sankar, the panel member who co-chairs of the DMTF Incubator, thought it had been a valuable session... But the crowd had also told him what he was up against as the incubator sets about proposing specs for cloud interoperability..."

NIST Draft on Key History for Personal Identity Verification (PIV) Cards
David A. Cooper (ed),

Draft NISTIR 7676 Maintaining and Using Key History on Personal Identity Verification (PIV) Cards has been released for review by the NIST Computer Security Division Information Technology Laboratory. This paper complements SP 800-73-3 by providing some of the rationale for the design of the mechanism for storing retired Key Management Keys on PIV Cards and by providing suggestions to smart card vendors, PIV Card Issuers, and middleware developers on the use of the Key History mechanism. NIST Special Publication 800-73-3 itself introduces the ability to store retired Key Management Keys within the Personal Identity Verification (PIV) Card Application on a PIV Card...

FIPS 201 specifies one mandatory and three optional asymmetric key pairs that may appear on PIV Cards: the PIV Authentication Key, the Card Authentication Key, the Digital Signature Key, and the Key Management Key. FIPS 201 requires that whenever one of these keys is present on the card, the corresponding X.509 certificate must also be stored on the card.

Storing the certificates on the card ensures that any application that has access to the private keys also has access to the corresponding certificates. In the case of the Key Management Key, it is likely that the only information about the cardholder's Key Management Key that an entity encrypting a message intended for the cardholder will use will be the X.509 certificate containing the public key. Ensuring that the PIV Card-using application also has access to the certificate ensures that the application will have access to all the information that it needs to determine whether the Key Management Key on the PIV Card was used to encrypt a particular encrypted message.

When the PIV Card Application is loaded onto a card, space may be allocated for zero to twenty retired Key Management private keys and their corresponding certificates. Space may be allocated for fewer certificates than private keys. Where space on the card is limited, it is recommended that priority be given to allocating space for as many retired Key Management private keys as possible while also allocating space for at least one retired X.509 certificate for Key Management. Storing at least one certificate on the card will ensure that the most recently retired Key Management Key will always be available for use, even when the PIV Card-using application cannot access the off-card certificate source. Maximizing the number of retired Key Management private keys that are stored on the card ensures maximal availability of older encrypted data whenever the PIV Card-using application has access to all of the corresponding certificates..."

Policies and Rules for Improving Business Agility
Maryann Hondo, Jerome Boyer, Andy Ritchie; IBM developerWorks

The ultimate goal of any architecture is to provide the business with direction on how to achieve the stated business targets, goals and objectives. Once a business driven need for agility had been identified, then using best practices and aligning specific products to meet the business requirements can be achieved and the architects can successfully build a fully automated intelligent solution.

The amount of variability around the application and management of policy and rules should be seen as an opportunity to bring tremendous agility to business services but it also requires businesses to establish their own principles of governance for the management of business rules and business policy as first class business assets.

The primary goal of this article (Part 1) is to present a strawman for a definition of the terms policy and rules and provide a context for evaluating both the relationship between policy and rules and the relationship between business analysts, architects and IT staff. Starting with a brief explanation of the relationship between business policies and business rules helps establish a context to evaluate how policies and rules can be used individually or in combination to implement/enforce business strategies, tactics and industry regulations.

The intent is to illustrate how architects can help business and IT achieve specific business goals and objectives that have been defined. To accomplish this goal in the first section of this paper, we propose definitions for the terms and make some assertions regarding the use of the terms and their relationship to one another. This part of the article can be seen to be more abstract, in that its focus is the relationships and representing business agility goals, which by nature are dynamic..."


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

Headlines

Sponsors