Cover Pages: XML Daily Newslink: Tuesday, 23 November 2010

Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
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:
Microsoft Corporation http://www.microsoft.com

Headlines

XML Message Encoding for Key Management Interoperability Protocol (KMIP)
Security Standards for Protecting Credit Card Data at the Point of Sale
OASIS SCA-J Technical Committee Submits Specifications for Review
OGC Approves Web Coverage Service (WCS) Interface Standard Version 2.0
What Android Is: Being an Illustrated Run Through the Basics
PayPal to Use Axiomatics' Intelligent Access Management Solution
OASIS Opens the Doors on WS-I Member Section
Taming the Metadata Beast: ILOX

XML Message Encoding for Key Management Interoperability Protocol (KMIP)
Hal Lockhart, Contribution to OASIS KMIP TC

The Key Management Interoperability Protocol (KMIP) 1.0 defines a single message encoding format called TTLV. As noted in the KMIP Version 1.0 Standard: "In order to minimize the resource impact on potentially low-function clients, one encoding mechanism to be used for protocol messages is a simplified TTLV (Tag, Type, Length, Value) scheme. The message encoding scheme is designed to minimize the CPU cycle and memory requirements of clients that need to encode or decode protocol messages, and to provide optimal alignment for both 32-bit and 64-bit processors. Minimizing bandwidth over the transport mechanism is considered to be of lesser importance."

"TTLV is well suited for simple and efficient processing, especially in resource-constrained environments. An equivalent XML encoding may be valuable in environments where most messages are already in XML.

Design Goals for XML encoding: Both encodings should convey the same semantics. All differences between encodings should be confined to one place in the spec, per Chapter 9. Changes to other parts of the specs should automatically work with both encodings. TTLV -> XML, XML -> TTLV and round tripping should all work. It should be simple to build Server which supports both. It should be simple to build bi-directional gateway. This implies no information loss in moving from one form to the other.

KMIP XML Conversion Principles: Use non-empty XML Elements to represent KMIP Objects. Use the current names given in KMIP spec as basis for naming in XML—remove spaces between words, use 'upper camel case' e.g. KeyWrappingData, dash character is OK as is, e.g., CommonTemplate-Attribute, Need to map '/' to something else e.g., MAC/Signature, perhaps dash, e.g, MAC-Signature (?), Single letter names might cause confusion, e.g., P, Q, X, Y - Perhaps CryptoP, CryptoQ, etc.... Data type: In TTLV data type is passed with object Parser needs to have access to Schema..." Still [2010-11-11] there are questions about custom extensions: what is level of support required? Are we assuming that mostly will be supporting custom extensions or their own? Could affect the design regarding how easy it is to consume someone else's custom extensions, e.g., vendor extensions? Custom attributes? [...]"

See also: the list of KMIP supporters [TOC]

Security Standards for Protecting Credit Card Data at the Point of Sale
Steve Brunswick and Jose Diaz, ComputerWorld

There is no shortage of security standards when it comes to protecting the payment transaction life cycle. Standards to protect PINs at the point of sale (POS), for example, have been in place for a number of years, but it is equally important to protect other types of cardholder data such as the primary account number (PAN) across the entire transaction process. There are three main initiatives underway today that apply to the protection of this data and aim to improve overall payment card security at the POS, between the POS and the acquiring bank and beyond.

While the POS security standard landscape may seem complicated, when these various initiatives are broken down and analysed, commonalities can be identified. What's more, the implementation of single security technologies, such as end-to-end encryption or tokenisation, can support compliance across all three initiatives.

The Secure POS Vendor Alliance's (SPVA) recent document on End-to-End Encryption Security Requirements is designed to help make transactions more secure. The SPVA is a nonprofit organisation that works with the multiple stakeholders of the payment value chain. In its own words, the SPVA aims to develop an end-to-end security framework and to enhance security elements of payment solutions, which protect cardholder information and defend merchants and acquirers against security breaches, while reducing fraud and lowering risk for all electronic payment stakeholders...

We can perhaps expect the SPVA document (which already refers to the predecessor to the PCI PTS-POI specification) and PCI PTS-POI to be updated in time to refer to the X9.119 standard, since they both already reference other X9 standards related to key management and encryption technology, thereby completing the circle..."

OASIS SCA-J Technical Committee Submits Specifications for Review
Mark Combellack, David Booz, Mike Edwards, Anish Karmarkar (eds), OASIS PRDs

Members of the OASIS Service Component Architecture / J (SCA-J) Technical Committee have approved two Committee Specification Drafts for public review through December 23, 2010. OASIS also welcomes interested parties to join the TC as it continues to further development of its specifications. The SCA-J TC defines the Java language binding for SCA components based on the SCA Assembly specification. The specifications include a client and implementation specification, a common annotations specification, Spring client and implementation specification, an EJB binding specification, and the J2EE integration specification.

The specification SCA-J POJO Component Implementation v1.1 TestCases Version 1.0 defines the TestCases for the SCA Assembly specification. The tests are related to the Test Assertions described in the SCA POJO Component Implementation Test Assertions document. The SCA J POJO-CI test cases follow a standard structure. They are divided into two main parts: (1) Test Client, which drives the test and checks that the results are as expected; (2) Test Application, which forms the bulk of the testcase and which consists of Composites, WSDL files, XSDs and code artifacts such as Java classes, organized into a series of SCA contributions...

The basic idea is that the Test Application runs on the SCA runtime that is under test, while the Test Client runs as a standalone application, invoking the Test Application through one or more service interfaces... The test client is designed as a standalone application. The version built here is a Java application which uses the JUnit test framework, although in principle, the client could be built using another implementation technology."

The specification SCA POJO Component Implementation v1.1 Test Assertions Version 1.0 defines the Test Assertions for the SCA POJO Component Implementation specification. The Test Assertions represent the testable items relating to the normative statements made in the SCA POJO Component Implementation specification. The Test Assertions provide a bridge between the normative statements in the specification and the conformance TestCases which are designed to check that an SCA runtime conforms to the requirements of the specification..."

OGC Approves Web Coverage Service (WCS) Interface Standard Version 2.0
Staff, Open Geospatial Consortium Announcement

The Open Geospatial Consortium has announced approval and availability of the OGC Web Coverage Service (WCS) Interface Standard, Version 2.0. The WCS 2.0 Implementation Standard is now available for download in four parts: OGC WCS 2.0 Interface Standard - Core; OGC Web Coverage Service 2.0 Interface Standard - KVP Protocol Binding Extension (1.0); OGC Web Coverage Service 2.0 Interface Standard - XML/SOAP Protocol Binding Extension (1.0); OGC Web Coverage Service 2.0 Interface Standard - XML/POST Protocol Binding Extension (1.0).

"The OGC WCS 2.0 standard defines a standard interface and operations that enable interoperable access to geospatial coverages. 'Coverages' are digital geospatial information representing space/time-varying phenomena, such as sensor data, satellite imagery, digital elevation models, and climate/ocean data. Services implementing this standard provide an interface with a standard set of operations for accessing original or derived sets of geospatial coverage information.

The WCS 2.0 standard has several significant enhancements over previous versions. WCS 2.0 is harmonized with the Geography Markup Language (GML) coverage model, leading to increased interoperability across OGC standards. Further, WCS 2.0 supports all GML and ISO coverage types, therefore extending WCS from pure raster data to point clouds, curvilinear grids, general meshes, and more coverage types. Additionally, WCS 2.0 is highly modular and follows the OGC's new Modular Specification Policy, which describes a design pattern that makes standards easier to understand and implement.

An important aspect of the WCS standard is that it allows access and retrieval of raw, unprocessed data, which is often required by rendering and processing services... The WCS 2.0 submission team includes representatives from: BAE Systems, ERDAS, GMU, Jacobs University Bremen, National Center for Atmospheric Research, Natural Environment Research Council (NERC), NOAA, Oracle, PCI Geomatics, and Spot Image..."

What Android Is: Being an Illustrated Run Through the Basics
Tim Bray, Blog

"[...] I wanted an Android architecture overview graphic and ran across, among the Android SDK documentation, a page entitled 'What is Android?' It's perfectly OK. Except for, I really disliked the picture — on purely aesthetic grounds, just not my kind of lettering and gradients and layouts — so I decided to make another one... I've been spending a lot of time recently explaining 'What Android Is' to people, I thought I'd provide my version of that as well, in narrative rather than point form.

First of all, as Dan Morrill memorably explained in On Android Compatibility, 'Android is not a specification, or a distribution in the traditional Linux sense. It's not a collection of replaceable components. Android is a chunk of software that you port to a device'... Underneath everything is a reasonably up-to-date Linux kernel with some power-saving extensions we cooked up...

The next big piece is Dalvik, comprising the VM and a whole bunch of basic runtime essentials. Its design is fairly unique, and judging by recent history, seems to be working out pretty well as a mobile-device app substrate. All the standard APIs that you use to create Android apps are defined in terms of Dalvik classes and interfaces and objects and methods.

Native code is currently produced more or less exclusively by compiling C or C++ code; but there's no reason it has to be that way... An Android app lives in what's called an APK, which is simply a ZIP file, with a particular internal file layout that allows it to be run in place, without unpacking. There's nothing magic about them, you can email them around and drop them on USB keys and extract pieces with unzip... The Android Manifest is the interface between an app and the Android system... I hope you like the pictures..." [see blog for pictures]

See also: the Android web site [TOC]

PayPal to Use Axiomatics' Intelligent Access Management Solution
Staff, Axiomatics Announcement

"Axiomatics, a leading independent XACML authorization solution supplier, is working with PayPal for its Attribute Based Access Control (ABAC) software solution. Servicing millions of users, PayPal operates an IT environment representing the largest XACML based authorization deployment to date.

In-line with continued advancements in security requirements, PayPal is using Axiomatics' intelligent access management solution, including the Axiomatics Policy Server (APS), the Axiomatics Policy Auditor (APA) and Axiomatics policy modeling know-how in the form of professional services. With this authorization system in place PayPal will be able to help secure its position as one of the world's leading provider of real-time, online payment solutions.

Axiomatics access management products utilize XACML 2.0 and the 3.0 draft to provide enterprise-wide, fine-grained, context aware authorization. They offer a complete security management system that can be integrated into virtually any existing IT platform. Furthermore, they enable users to achieve a paradigm shift from a static, pre-configured authorization model to dynamic, real-time evaluation of access requests.

Michael Barrett PayPal's chief information security officer: At PayPal our customers rely on our ability to ensure that payment procedures are secure at all times. Attribute Based Access Control will provide us with the security we require to maintain the high-level of security our customers expect from PayPal'. Gerry Gebel, President of Axiomatics' Americas Division: 'We are very pleased to be working with PayPal, which, among other things, is the result of a lot of hard work by a number of key personnel at Axiomatics. This confirms our belief that ABAC solutions are the way forward for companies that require a single solution that enables new business opportunities, solves compliance headaches and simplifies the access and control process'..."

OASIS Opens the Doors on WS-I Member Section
Mark Little, InfoQueue

"Just five months after OASIS announced their collaboration with WS-I, and just after the recent announcement from WS-I that they are closing and moving their efforts to OASIS, a new Web Services Interoperability Member Section has been created and announced.

As the new committee pages state: 'The OASIS Web Services Interoperability (WS-I) Member Section advances Best Practices for selected groups of standards, across platforms, operating systems, and programming languages. WS-I comprises a diverse community of Web services leaders from a wide range of organizations. OASIS WS-I Technical Committees maintain Profiles and supporting Testing Tools for standards. The Profiles and Testing Tools are available for use by the community to aid in developing and deploying interoperable Web services'.

The steering committee consists of participants from Oracle, Microsoft, IBM, Oracle and others, all members and contributors to the original work from the WS-I. The governance rules for the committee are similar to other Member Sections within OASIS: The WS-I Steering Committee consists of nine members, each serving a two-year term. For consistency of management, terms are staggered so that five seats expire one year and the other four expire the following year'...

It's obviously early days, with calls to join and advance the effort only just going out. However, it will be interesting to see how much activity occurs within this new Member Section and how far they advance the work begun by the WS-I. Other Member Sections, such as the OpenCSA, which has been working on standardizing the original SCA donations from the likes of IBM and Oracle, have been fairly successful in broadening their membership and applicability..."

Taming the Metadata Beast: ILOX
David Massart, Elena Shulman, Nick Nicholas (et al), D-Lib Magazine

In this article "we propose a framework for organizing multiple metadata specifications in a container that can be handled as a whole. This framework, named Information for Learning Object eXchange (ILOX), is developed as part of the IMS Learning Object Discovery & Exchange (LODE) specification that aims to facilitate the discovery and retrieval of learning objects stored across more than one collection. While thus far ILOX has been demonstrated to resolve a number of challenges specific to the e-learning domain, it is a generic framework that can be profiled to organize metadata about any type of digital content.

In information modeling, materialization is used to represent the relationship between a class of categories (e.g., learning objects) and a class of more concrete items (e.g., learning object copies). Materialization is important in formulating metadata for learning objects, because it captures commonalities between descriptions of objects at different levels of generality: metadata attributes may apply at a more abstract level, to a larger number of instances, or at a more concrete level, to a smaller number of instances.

The ILOX data model structures a learning object description as a materialization hierarchy, where the FRBR materialization levels are used as follows: (1) Work is an abstract view of a learning object that captures the commonalities between all the possible variations of this learning object such as, for example, the pedagogical content that is common across all the variations of the learning object. (2) Expressions are used to capture information specific to the different versions, drafts, translations, and localizations of learning objects, such as language. (3) Manifestations are used to capture information specific to the way a given expression of a learning object is encoded and presented, such as file formats. (4) Items are used to capture information specific to the concrete copies of learning objects, such as the URI where they can be accessed...

Using ILOX in combination with LOM and other metadata specifications makes it possible to organize all these specifications in one metadata container. Using level specific attributes at the ILOX Expression and Manifestation levels makes it possible to provide information on the ways versions differ from one another and then provides information allowing for the efficient retrieval of those versions in all their available formats and locations. The facet mechanisms of the ILOX allow for social and meaningful actions' data to follow a learning object through its life cycle. When different versions or formats have special features or specific rights' stipulations, these can also be effectively expressed all in one metadata container..."


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

Headlines

Sponsors