The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
Advanced Search
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

Cover Stories
Articles & Papers
Press Releases

XML Query

XML Applications
General Apps
Government Apps
Academic Apps

Technology and Society
Tech Topics
Related Standards
Last modified: March 24, 2010
XML Daily Newslink. Wednesday, 24 March 2010

A Cover Pages Publication
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation

OASIS Public Review for Common Alerting Protocol (CAP) Version 1.2
Jacob Westfall (ed), OASIS Public Review Draft

Members of the OASIS Emergency Management Technical Committee have submitted an approved Committee Draft of Common Alerting Protocol (CAP) Version 1.2 for public review through April 08, 2010. The Common Alerting Protocol (CAP) "is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as might indicate an undetected hazard or hostile act. And CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience.

The CAP specification provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats including the Specific Area Message Encoding (SAME) used for the United States' National Oceanic and Atmospheric Administration (NOAA) Weather Radio and the Emergency Alert System (EAS).

Enhanced capabilities include: (1) Flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; (2) Multilingual and multi-audience messaging; (3) Phased and delayed effective times and expirations; (4) Enhanced message update and cancellation features; (5) Template support for framing complete and effective warning messages; (6) Compatible with digital encryption and signature capability; (7) Facility for digital images and audio.

Key benefits of CAP will include reduction of costs and operational complexity by eliminating the need for multiple custom software interfaces to the many warning sources and dissemination systems involved in all-hazard warning. The CAP message format can be converted to and from the native formats of all kinds of sensor and alerting technologies, forming a basis for a technology-independent national and international warning internet..."

See also: OASIS Emergency Management TC specifications

Extensions to the IODEF-Document Class for Reporting Phishing
Patrick Cain and David Jevans (eds), IETF Internet Draft

The Internet Engineering Steering Group (IESG) has announced approval of the specification Extensions to the IODEF-Document Class for Reporting Phishing as an IETF Proposed Standard. "Deception activities, such as receiving an email purportedly from a bank requesting you to confirm your account information, are an expanding attack type on the Internet. The terms phishing and fraud are used interchangeably in this document to characterize broadly- launched social engineering attacks in which an electronic identity is misrepresented in an attempt to trick individuals into revealing their personal credentials ( e.g., passwords, account numbers, personal information, ATM PINs, etc.). A successful phishing attack on an individual allows the phisher (i.e., the attacker) to exploit the individual's credentials for financial or other gain. Phishing attacks have morphed from directed email messages from alleged financial institutions to more sophisticated lures that may also include malware.

This document extends the Incident Object Description Exchange Format (IODEF) to support the reporting of phishing, fraud, other types of electronic crime, and widespread spam incidents. The Incident Object Description Exchange Format specified in RFC 5070 defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. RFC 5070 describes the information model for the IODEF and provides an associated data model specified with XML Schema.

The extensions in Extensions to the IODEF-Document Class for Reporting Phishing are specified in XML and are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle. Both simple reporting and complete forensic reports are possible, as is consolidated reporting of multiple phishing incidents. The extensions may be used to report the social engineering victim lure, the collections site, and credential targeted ('spear') phishing, broad multi-recipient phishing, and other evolving Internet-based fraud attempts. Malware and other malicious software included within the lure may also be included within the report... By using a common format, it becomes easier for an organization to engage in this coordination as well as correlation of information from multiple data sources or products into a cohesive view.

Working Group Summary: Testing and implementation of this document in the INCH WG had major impact on the base IODEF Document as these tests were the first time that portions of IODEF were used. The Anti-Phishing Working group, and Sparta, Inc (under US gov't funding) have independent implementations that create and accept the formats defined in this document. There are a handful of CSIRTs and fraud-repository organizations who have agreed to share data using this format. The XML defined in this document was validated using multiple XML tools by more than one party.

See also: Application Security Standards

CFP: 8th International Conference on Scalable Vector Graphics
Staff, SVG Open Conference Announcement

The deadline for submission of paper abstracts for the Eighth International Conference on Scalable Vector Graphics is Marcy 31, 2010. Presenters are asked to submit an extended abstract in English with an approximate length of 400 to 800 words. The abstracts are reviewed by a reviewing committee (2 reviews per abstract) and presenters will be informed about acceptance on or before May 12. If your abstract is accepted, you will be asked to submit your full paper by July 31, 2010 according to instructions that will be sent to you. Accepted abstracts, papers and presentations will be published in web proceedings.

According to W3C's announcement: "With Scalable Vector Graphics (SVG) support announced for all major browsers, there is an uptake in interest in SVG. W3C joins other sponsors to help with SVG Open 2010, the 8th international conference on Scalable Vector Graphics, to be held in Paris, France from August 30 to September 1, 2010. SVG Open provides an opportunity for designers, developers and implementers to learn about SVG, and share ideas, experiences, products, and strategies... The conference will include a Working Group panel session on future SVG developments, and an implementers panel. The conference also includes a day of workshops."

A list of potential presentation topics is published on the conference web site: Mobile (handheld, in-car) Solutions; SVG Authoring Tools; Publishing and Printing with SVG; SVG Text and Internationalization; Accessibility Issues with SVG; Location-based Services; Business Cases and Case Studies; Workflow for Creating and Using SVG; SVG and Digital Television; Graphic Design with SVG; SVG for Webmapping and Online GIS/GML; SVG for Multimedia Presentations; Server-side SVG Generators and Manipulators; SVG Authoring Techniques; SVG with Other Web Standards; Interactivity and Scripting; GUI Frameworks for Web Applications; File Format Conversion..."

The full paper format is the article subset of DocBook 5.0. The DocBook documents will be translated to XHTML, using XSLT. There is the official DocBook 5 specification, a free downloadable DocBook book, a DocBook FAQ and a DocBook XSLT book available to help you get started. Many XML editors (such as OxygenXML) also provide ready to use docbook environments for validation and XSLT transformation..."

See also: the W3C news item

IETF Informational RFC: A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies
Volker Hilt and Gonzalo Camarillo (eds), IETF Approved RFC

The Internet Engineering Steering Group (IESG) recently announced the publication of A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies as an Informational RFC. The SIP event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change.

The Framework for Session Initiation Protocol (SIP) (RFC 3261) Session Policies defines a protocol framework that enables a proxy to define and impact policies on sessions such as the codecs or media types to be used. This framework identifies two types of session policies: session-specific and session-independent policies. Session-specific policies are policies that are created for one particular session, based on the session description of this session. They enable a network intermediary to inspect the session description a UA is proposing and to return a policy specifically generated for this session description.

Since session-specific policies are tailored to a session, they only apply to the session they are created for. A user agent requests session-specific policies on a session-by-session basis at the time a session is created and the session description is known. Session- independent policies on the other hand are policies that are created independent of a session and generally apply to all the SIP sessions set up by a user agent.

This specification defines a SIP event package that enables UAs to subscribe to session-specific policies on a policy server. Subscribing to session-specific policies involves the following steps: (1) A user agent submits the details of the session it is trying to establish to the policy server and asks whether a session using these parameters is permissible. For example, a user agent might propose a session that contains the media types audio and video. (2) The policy server generates a policy decision for this session and returns the decision to the user agent [deny, change, accept]. (3) The policy server can update the policy decision at a later time..."

See also: the IETF Session Initiation Proposal Investigation (SIPPING) Working Group

Leonard Richardson: Three Levels of the REST Maturity Model
Boris Lublinsk, InfoQueue

"In a recent article Martin Fowler is using the 3-level model of restful maturity that was developed by Leonard Richardson to explain web-style systems. Throughout his explanation Fowler uses an example of a service for booking a doctors appointment. According to Fowler, the starting point for the maturity model is to use HTTP purely as a transport system for remote interactions. In this case there is a single service -- appointment service, which is using a single method call (POST in his example) and an XML input/output to communicate specific requests and replies...

Excerpts from "Richardson Maturity Model: Steps Toward the Glory of REST": What I find useful about the RMM is that it provides a good step by step way to understand the basic ideas behind restful thinking. I don't think we have enough examples yet to be really sure that this approach is the right way to integrate systems, I do think it's a very attractive approach and the one that I would recommend in most situations. Talking about this with Ian Robinson, he stressed that something he found attractive about this model when Leonard Richardson first presented it was relationship to common design techniques. (1) Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources. (2) Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation. (3) Level 3 introduces discoverability, providing a way of making a protocol more self-documenting. The result is a model that helps us think about the kind of HTTP service we want to provide and frame the expectations of people looking to interact with it...

Level 0: The starting point for the model is using HTTP as a transport system for remote interactions, but without using any of the mechanisms of the web. Essentially what you are doing here is using HTTP as a tunneling mechanism for your own remote interaction mechanism, usually based on Remote Procedure Invocation... Level 1 - Resources: The first step towards the Glory of Rest in the RMM is to introduce resources. Level 2 - HTTP Verbs: In the example HTTP POST verbs are used for all my interactions in level 0 and 1, but some people use GETs instead or in addition. At these levels it doesn't make much difference, they are both being used as tunneling mechanisms allowing you to tunnel your interactions through HTTP. Level 2 moves away from this, using the HTTP verbs as closely as possible to how they are used in HTTP itself...

Level 3 - Hypermedia Controls: The final level introduces something that you often hear referred to under the ugly acronym of HATEOAS (Hypertext As The Engine Of Application State). It addresses the question of how to get from a list open slots to knowing what to do to book an appointment. There's no absolute standard as to how to represent hypermedia controls. What I've done here is to use the current recommendations of the REST in Practice team, which is to follow ATOM so I use a 'link' element with a 'uri' attribute for the target URI and a 'rel' attribute for to describe the kind of relationship. A well known relationship (such as self for a reference to the element itself) is bare, any specific to that server is a fully qualified URI. ATOM states that the definition for well-known linkrels is the Registry of Link Relations . As I write these are confined to what's done by ATOM, which is generally seen as a leader in level 3 restfulness..."

See also: Martin Fowler's article

Is Cloud Computing More Secure?
Dan Lohrmann, Government Computing

Dan Lohrmann is Michigan's Chief Technology Officer and was the state's first Chief Information Security Officer (CISO). He has more than 24 years of worldwide technology experience, and has won numerous awards for leadership in the information security field.

"Michigan has an exciting cloud strategy, like many other states. In fact, most technology vendors I know have one or more game-changing cloud offerings. But this [article] is about cloud security and specifically whether cloud computing is more secure than whatever your government is doing now. If you currently have weak security controls, you may be tempted to hand over your sensitive data to a cloud provider -- but read on before you do...

What are a few of the most pressing cloud security problems? (1) Our duty is to protect sensitive information, not just systems. Even if large cloud providers can protect servers better, your legal responsibility is to secure the information end-to-end. (2) Off-the-shelf cloud policies, processes and procedures will probably not meet your need to comply with legal mandates, such as the Payment Card Industry compliance. (3) Where is your data? The global cloud knows no international borders, allowing for cheaper hosting overseas. But do laws (in other countries, like China) provide adequate protection of your rights if your provider goes bankrupt or doesn't comply with agreements? (4) Who owns and has access to view the logs at your cloud provider? Does this satisfy your audit responsibilities? Are e-discovery issues addressed? (5) In the event of a data breach, will your cloud provider be responsible for relevant costs? In most cases, state governments cannot indemnify contractors or hold them harmless...

How to proceed? [...] utilize cloud computing for publicly available data that's already accessible via the Freedom of Information Act. Large amounts of our government information can be placed in the cloud without risking breaches or many of the other issues identified. [And] start talking with your vendor partners about new ways to secure your data in the cloud. There are many innovative technologies that are coming soon. I believe that the opportunities are huge over the next decade, and we need to build legal compliance into our plans..."

Apple iPhone, Firefox, Safari, and IE Fall in Hacking Contest
Brian Prince, eWEEK

"Score another for the hacker community. At the Pwn2Own contest at this week's CanSecWest Applied Security conference in Vancouver, hackers have had their way with the Apple iPhone, Mac and Safari, as well as Mozilla Firefox and Microsoft Internet Explorer... According to contest rules, the details of the vulnerabilities must be disclosed to the affected vendors.

The iPhone fell courtesy of Vincenzo Iozzo of Zynamics and independent security researcher Ralf-Philipp Weinmann, who developed an attack that bypassed the code signing and data execution prevention features that prevent arbitrary code from running. To this, they 'chained existing code bits' in a technique known as return-into-libc or return-oriented-programming... It is the first time that this technique has been publicly demonstrated on a real-world telephone...

The Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) protections in Windows 7 were circumvented by contestants as part of their efforts to exploit Firefox and Internet Explorer (IE) 8. A researcher from U.K.-based MWR Info Security circumvented the ASLR and DEP features on Windows 7 and exploited a flaw in Firefox. In an interview, he explained that part of the issue was Mozilla's 'implementation of the protection mechanisms themselves, and that getting around Microsoft's protections was the hardest part of the attack...

Mac security researcher Charlie Miller of Independent Security Evaluators once again took down the Mac OS X operating system, this time using a drive-by download attack on Safari 4 to get control of the computer..."

See also: CanSecWest


XML Daily Newslink and Cover Pages sponsored by:

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

XML Daily Newslink:
Newsletter Archive:
Newsletter subscribe:
Newsletter unsubscribe:
Newsletter help:
Cover Pages:

Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation


XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI:  —  Legal stuff
Robin Cover, Editor: