This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com
- OASIS Call for Public Review: WS-SecurityPolicy Examples
- W3C Call for Review and Implementation of OWL Version 2
- ISO/IEC JTC1/SC34 Call for Review: Topic Maps Constraint Language
- Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
- SOA Manifesto and the Second International SOA Symposium
- REST and Transactions?
- Conversation Between Intelligent Buildings and Smart Energy
- Using OpenADR to Automate Smart Grid Market Participation
- Opera 10 Alpha: Services for Sharing Files, Music and Photos, Hosting
OASIS Call for Public Review: WS-SecurityPolicy Examples
R. Levinson, T. Gullotta, S. Chang, M. Raepple (eds), OASIS Public Review Draft
Members of the OASIS Web Services Secure Exchange (WS-SX) Technical Committee have released an approved Committee Draft of "WS-SecurityPolicy Examples" for public review through August 14, 2009. "The purpose of this document is to provide examples of how policies may be defined for several existing use cases that have been part of the WS-Security Interopability Scenarios that have been conducted. In addition, some example use cases have been included which show some variations from the WS-Security Interopability use cases in order to demonstrate how different options and security bindings impact the structure of the policies. Specifically, it contains examples of how to set up WS-SecurityPolicy policies for a variety of common token types that are described in WS-Security 1.0 and WS-Security 1.1 token profiles. Particular attention is focused on the different 'security bindings' (defined in WSSP) within the example policies. Actual messages that have been documented in WS-Security TC and other WS-Security-based Interopability Scenarios that conform to some of the example policies are referenced when appropriate.
Three important conceptual entities exist on the initiating side of a transaction, where the transaction is being requested by sending an electronic message that contains the details of the what is being requested and by whom; the 'entities' become 'actors' as the discussion moves from the conceptual to the specific. These three entities are: (1) The entity requesting the transaction—for example, if the transaction is about an application for a home mortgage loan, then the entity requesting the transaction is the prospective homeowner who will be liable to make the payments on the loan if it is approved. (2) The entity approving the transaction to be requested, generally known as an 'identity provider', or an 'authority' [...] to guarantee to a recipient entity that the requesting entity is making a legitimate request; (3) The entity initiating the actual electonic transaction message.
The document's purpose is not to provide unequivocable answers to all questions regarding liability of transactions, but to give a sense of how the structuring of a request message ties the participating entities to the transaction. Depending on how the WS-SecurityPolicy technology is used, these 'ties' can be relatively stronger or weaker. Depending on the nature of the transactions supported by a particular Web Application, the system managers of the Web Services Application being protected using WS-SecurityPolicy techniques, may be interested in a conceptual framework for understanding which WS-SP techniques are more or less appropriate for their needs..."
See also: the OASIS WS-SX Technical Committee
W3C Call for Review and Implementation of OWL Version 2
Christine Golbreich, Evan K. Wallace (et al, eds), W3C Technical Reports
The W3C OWL Working Group now "invites implementation of its OWL 2 Web Ontology Language. The OWL Web Ontology Language is designed for use by applications that need to process the content of information instead of just presenting information to humans. OWL facilitates greater machine interpretability of Web content than that supported by XML, RDF, and RDF Schema (RDF-S) by providing additional expressive power along with a formal semantics.
OWL 2 is a compatible extension to OWL 1, providing additional features for people using ontologies. An ontology is a structured set of terms that a particular community uses for organizing data, such as "title", "author", and "ISBN" for data about books. The OWL 2 document set contains nine (9) technical specifications and four (4) instructional documents. The Recommendation-track specifications are now Candidate Recommendations, indicating that the Working Group and the W3C Director believe this is a good time for systems to begin adopting OWL 2 features on an experimental basis. The group maintains a list of implementations and encourages new information about implementations and other feedback to be sent to the comment list. The four instructional documents, which provide an introduction to OWL 2, are now at Last Call: overview, primer, new features and rationale, and quick reference. Finally, a new datatype used within both OWL and RIF, called 'rdf:PlainLiteral' (formerly called rdf:text) is also at Candidate Recommendation stage..."
See also: the W3C OWL Working Group
ISO/IEC JTC1/SC34 Call for Review: Topic Maps Constraint Language
Lars Marius Garshol and Graham Moore (eds), ISO/IEC JTC1/SC34 Draft
A new draft of the Topic Maps Constraint Language (TCML) has been produced by members of JTC1/SC34. TCML (ISO 19756) is a language for defining schemas and constraints on topic map models. Specifically, TMCL can be used to constrain instances of Topic Maps Data Model. The constraint language provides a constraint model, related validation semantics, and CTM syntax templates for authoring constraints. TMCL defines a Topic Maps vocabulary for representing constraints on Topic Maps ontologies, defined using English prose. The vocabulary is defined in terms of validation, that is, verifying whether or not a given topic map conforms to the constraints.
The TMCL validation rules are defined using constructs from the Topic Maps — Data Model" (TMDM), and their meanings are given in English prose following certain conventions, whereby some of the phrases in the text have particular interpretations. Other normative references are provided for Topic Maps — Query Language (TMQL) and Topic Maps — Compact Syntax (TCM).
According to an editors' communication, the WG believes that the shape of the specification, the templates, and the PSIs are all fairly stable. They solicit "feedback on this version, and especially feedback from implementors on whether they can understand and implement the specification, and whether they believe different implementors will implement it the same way."
See also: Topic Maps reference document
Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
Russell Housley and Morris Dworkin (eds), IETF Internet Draft
IETF announced the release of an updated Internet Draft for Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm, intended for publication as an Informational RFC. Abstract: This document specifies a padding convention for use with the AES Key Wrap algorithm specified in 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 '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 use of a 32-bit fixed field to carry the octet length of the key data bounds the size of the input at 2^32 octets. Most systems will have other factors that limit the practical size of key data to much less than 2^32 octets.
Security Considerations: "Implementations must protect the key-encryption key (KEK). Compromise of the KEK may result in the disclosure of all keys that have been wrapped with the KEK, which may lead to the compromise of all traffic protected with those wrapped keys. The KEK must be at least as good as the keying material it is protecting..."
See also: Cryptographic Key Management
SOA Manifesto and the Second International SOA Symposium
Thomas Erl (et al.), Industry Announcement
The "SOA Manifesto" now in draft is a "formal declaration of the principles, intentions and ambitions of service-orientation and the service-oriented architectural model." The Working Group called "Towards an SOA Manifesto" is dedicated to producing this SOA Manifesto. An initial draft of the SOA Manifesto will be announced for the first time on October 23, 2009 during the closing conference keynote at the Second International SOA Symposium in Rotterdam, The Netherlands. The first draft of the SOA Manifesto will be published soon afterwards on the 'soa-manifesto.com' web site in early November 2009, following the release of documents finalized by the working group during a series of workshops held October 22-23, 2009 at the World Trade Center in Rotterdam as part of the Second International SOA Symposium.
In this context, "SOA" is a 'distributed technology architectural model with distinct characteristics in support of realizing service-orientation'. "Service-Orientation" is a 'design paradigm comprised of a set of principles that shape software programs into units of service-oriented logic in support of attaining a pre-defined target state represented by the goals of service-oriented computing.'
According to Erl: "Next Generation SOA represents how the evolution of service-oriented computing has reached a point where we have not just mature technology platforms and sophisticated modern service technology innovations at our disposal, but also proven practices, patterns, principles, and a clear vision of the target state represented by service-oriented computing."
See also: the SOA Manifesto WG web site
REST and Transactions?
Mark Little, InfoQueue
There has been a long debate about the benefits of REST versus other approaches (notably Web Services), or simply the benefits of using it for Web-based integrations. The discussions continue, but several people have begun to try to move the debate to whether or not there are certain capabilities we take for granted elsewhere that are missing in REST, or specifically in REST-over-HTTP. One of those things is distributed transactions and there has been a recent to-and-fro on the REST-discuss mailing list, triggered when Bill Burke pointed people at an implementation done on RESTeasy and asked for comments... The discussion continues, but there seems to be no clear answer to whether or not (extended) transactions really do fit in a REST world. However, it does seem conclusive that many people believe they need them for one reason or another...
Conversation Between Intelligent Buildings and Smart Energy
Toby Considine, AutomatedBuildings.com
One view of how the Smart Grid will develop: "Intelligent buildings filled with clever devices and intelligent systems will negotiate with the grid and with their occupants to provide new models for reliable power. The benefits to the grid will come from coordinating supply and demand using economic signals... The benefit to building integrators will be national markets based on common signals from the grid, allowing them to provide more services to those owners for less. The benefit to ventures and technology development will be the entry of all those building owners into the markets for generation and storage; those owners will offer a shorter sales cycle and more openness to innovation than ever will the utilities...
Each building will communicate with the grid by two services: the metering service and the energy management services (EMS)... The metering service (which does not necessarily mean the meter) will provide live and interval measurement of energy flows into and out of the building. This service will be symmetrical, meaning both the supplier and the consumer will be able to see the same information at the same time. The meter service will also be the end point of the energy distribution control system, providing telemetry to enhance customer service and downtime recognition. The EMS will be the focus of business interactions. On the outside, the EMS will manage the business negotiations for each building. On the outside of the building, the EMS will be the locus of energy market operations. Buying, selling, and price decisions will flow to and from the outside of the EMS... The smart grid roadmap cites loose coupling, layered architectures, composition, and symmetry as critical design values. The EMS as defined above uses loose coupling and avoids direct control. Symmetry enables us to define the same services on either side of the EMS, and for the meters to report net use and net supply identically..."
Using OpenADR to Automate Smart Grid Market Participation
Ed Koch and Ken Sinclair, AutomatedBuildings.com
From the interview with Ed Koch, Co-Founder and CTO of Akuacom. Koch: "There are current opportunities to participate in wholesale and retail markets, and research or pilot programs funded by the Smart Grid stimulus package. Beginning next year all the IOUs in California will be offering new dynamic pricing tariffs that facilities with interval meters will be in by default. This represents a large near term deployment expansion opportunity. In April the CAISO launched its new Market Redesign and Technology Update (MRTU) that offers new opportunities in the wholesale market. Across the US, wholesale markets are offering a variety of programs including voluntary load response, day-ahead markets, real-time markets, and ancillary services for responsive reserve, non-spin reserve, and regulation up/down...
While the data models of OpenADR are agnostic to the various control networks within the facility there has been a conscious effort to insure that OpenADR is designed to facilitate the consumption of DR signals by control systems in general. This means that care has been taken to design the data models to allow easy consumption of the signals by control systems and to allow for facility managers and integrators to easily devise rules for how to respond to the signals so that the desired control strategies can be specified and implemented... OpenADR is already in use in CA and with its status as a key emerging standard the potential markets that will utilize OpenADR are poised to increase rapidly. With the new dynamic pricing tariffs in CA that will come into existence next year there will emerge a huge potential marketplace for facilities to automate their load management and by extension for control vendors to sell into..."
Opera 10 Alpha: Services for Sharing Files, Music and Photos, Hosting
Gregg Keizer, ComputerWorld
See also: the Introduction to Opera Unite
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/