Cover Pages: XML Daily Newslink: Tuesday, 28 October 2008

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

Harmonized Federation Metadata for WS-Federation and SAML
Yahoo Opens Up Big Time
Portable Contacts API and Vendor Relationship Management (VRM)
OAuth Access Tokens Using Credentials
XRI as Relative URI: Much Better
XML 1.0 5th Edition
Trying to Figure Out Where Open Formula Fits In
Public Review of Open Document Format v1.0 Errata

Harmonized Federation Metadata for WS-Federation and SAML
Don Schmidt, Blog

The fundamental purpose of federated identity is to enable subjects to use identities managed in one realm to gain authorized access to resources managed in other realms. Requests to access resources are authenticated and authorized by the exchange of security tokens and the claims they contain. Before seamless federated access can be granted, Identity Providers and Service Providers must configure their servers to agree on the types of tokens and claims that will be exchanged, and the keys that will be used to sign and encrypt them. This configuration data is generically referred to as 'federation metadata'; early implementations required this metadata to be manually entered on both sides of the relationship, which can be extremely error prone due to the lengthy URIs involved. A huge improvement in administrative efficiency can be gained by automating this configuration. The key to automation is enabling IPs and SPs to publish their federation metadata in a standard format which can be exchanged between potential partners. The Shibboleth community has demonstrated the effectiveness of this approach. The SAML 2.0 standard includes the Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 specification that is devoted to standardization of a federation metadata format... Federation metadata has also been a critical component of the WS-Federation specification that was submitted to OASIS. A key goal has been to develop a single specification that can support both passive web application and active web service requestors. In the interests of promoting engineering efficiencies for developers, and interoperability enhancements for deployers, the WSFED TC decided to make a substantive change to its federation metadata document structure during the first Public Review cycle. WS-Federation has been revised to take a normative dependency on the SAML 2.0 federation metadata document structure. The original format has been deprecated, although it is supported for backwards compatibility with early implementations...

Yahoo Opens Up Big Time
Erick Schonfeld, TechCrunch

Six months after first announcing its open strategy, Yahoo has released a slew of development tools under the Y!OS 1.0 platform. It's kind of like a Web OS, but Y!OS officially stands for Yahoo Open Strategy. As part of its strategy to remain one of the most popular starting points on the Web, Yahoo is making it much easier for data, content, and applications to flow in and out of Yahoo. It is also adding a layer of social awareness to everything it does. Features include: (1) Access to your and your friends' activity streams both on Yahoo and elsewhere on the Web; (2) A single, universal Yahoo profile; (3) A portable address book that you can take to other sites; (4) More customization features that let you bring content from other sites more easily into Yahoo; (5) Social networking features that help you connect to more people on Yahoo... Specifically, the Y!OS consists of several developer components, which you can read more about on Yahoo's developer blog or its developer network site. The components are Yahoo Social Platform (YSP), Yahoo Query Language (YQL), Yahoo Application Platform (YAP), and OAuth... The Yahoo Social Platform is a set of RESTful APIs for Profiles, Connections, Updates, Contacts and Status. These APIs enable developers to pull out information about users, their activity, and their contacts from Yahoo and use it elsewhere on the web. The Yahoo Query Language is a web service that functions much like SQL and creates a common interface for accessing data from both Yahoo and across the Web. It's described as 'a command line version of Pipes' since it simplifies the process of mashing up data from Yahoo and elsewhere... The Yahoo Application Platform allows Open Social-based apps to be built and distributed across Yahoo's own pages (MyYahoo, Yahoo Mail, category pages, etc). For now, apps on this platform can only be created in a restricted sandbox. But in the coming months, Yahoo will begin opening up its various properties for the integration of applications. Finally, OAuth is the authentication and authorization standard Yahoo has decided to use when giving third parties access to Yahoo user data.

See also: Jay Rossiter's blog

Portable Contacts API and Vendor Relationship Management (VRM)
Doc Searls, Blog

The Portable Contacts API looks to me like it could (and maybe should) be one of the open source building blocks for VRM. David Recordon [has prepared a video]. If you love energetic hack-a-thons (and you should; much of the code we all use was born in these fecund environments), there's much to be encouraged about... Joseph Smarr and Kevin Marks of Google hacked together a web transformer that integrates Microformats, vCard, and the Portable Contacts API. Given Kevin's homepage which is full of Microformats, they've built an API that extracts his profile information from hCard, uses a public API from Technorati to transform it to vCard, and then exposes it as a Portable Contacts API endpoint. Not only does this work on Kevin's own page, but his Twitter profile as well which contains basic profile information such as name, homepage, and a short bio. Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth... I suggest lining up a session or two at IIW to connect the Portable Contacts API and related VRM work on items such as personal data stores.

OAuth Access Tokens Using Credentials
Bill de hOra and Stephen Farrell (eds), IETF Internet Draft

IETF has published an initial level -00 Internet Draft for "OAuth Access Tokens Using Credentials." The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication. The "OAuth Access Tokens Using Credentials" specification defines a technique for allowing a user to provide their crendentials in cases where HTTP redirection to a browser is unavailable or unsuitable, such as intermediary aggregators and mobile or settop devices. Authentication Request: To request an Access Token in this model, the Consumer makes an HTTP request to the Service Provider's Access Token URL. The authentication request contains [nine] parameters... The parameters are contained in the HTTP Authorisation header or as URL parameters. Parameter names and values must be "percent-encoded" to handle characters in different character sets. The request should be performed using TLS, and should use HTTP POST. Authentication Response: To grant an access token, the Service Provider must ensure that the request signature has been successfully verified as per OAuth, that a request with the supplied timestamp and nonce has never been received before, and that the supplied username and password match a User's credentials. If successful, the Service Provider generates an Access Token and Token Secret using a 200 Ok response and returns them in the HTTP response body. Accessing Protected Resources: After successfully receiving the Access Token and Token Secret, the Consumer is able to access the Protected Resources on behalf of the User as per section 7 of the OAuth core specification. In other words, the Access Token obtained here is no different in capability to the Access Token specified by OAuth. Once authenticated using the above process, the Consumer will sign all subsequent requests for the User's Protected Resources using the returned Token Secret...

See also: OAuth

XRI as Relative URI: Much Better
Dave Orchard, Blog

"The [OASIS] XRI TC has published their XRI as Relative URI proposal and it alleviates my concerns with the part of XRI that deals with the new XRI: scheme. I think it's a great way of doing what they'd like to do with abstract identifiers that fits into the web architecture. This removes the largest concern that I raised in 'Detailed technical reasons why I'm against XRIs', which was that XRIs were a replacement for URIs. I won't stand against this XRI proposal at OASIS, and I'd probably concur with a TAG position that said the TAG's concerns have been alleviated. I think this has been really awesome work by the XRI TC to revamp their work based on external feedback....I think the end result is very strong technically. The XRI TC could have just tried to do a revote and pass their original proposal, but the leadership of folks like John Bradley really made for a superior result. Kudos to them. Having said all that, my concern that I think that the part of XRIs where people pay for i-names and i-numbers is a replacement for DNS/ICANN still stands. But in this new URI proposal, I think the market will decide very quickly that paying for alternative naming schemes is not worth it, so I'm prepared to let the market decide that issue..."

XML 1.0 5th Edition
James Clark, Random Thoughts Blog

"I sent a comment in on the proposed XML 1.0 5th Edition. For some background, read Norman Walsh, John Cowan, David Carlisle and Henry Thompson. There is a real problem here, and it's partly my fault. If we had had a bit more foresight ten years ago, we would have made the first edition of XML 1.0 say what is now being proposed for the 5th Edition. I know that the XML Core WG are trying to do the right thing, but I really don't think this is a good idea. I think you've got to look at the impact of the change not just on XML 1.0 but on the whole universe of specs that are built on top of XML 1.0. In an ideal world, all the specs that refer to XML 1.0 would have carefully chosen whether to make a dated or an undated reference to XML 1.0, and would have done so consistently and with a full consideration of the consequences of the choice. In practice, I don't believe this has happened. Indeed, before the 5th edition, I believe very few people would have considered that XML might make a fundamental change to its philosophy about which characters were allowed in names while still keeping the same version number... Now you can argue that the breakage and chaos that the 5th edition would cause is due to bugs in the specs that reference XML 1.0. But that doesn't make the breakage any less real. I also have the rather heretical view that the benefits of the change are small. In terms of Unicode support, what's vitally important is that any Unicode character is allowed in attribute values and character data. And XML 1.0 has always supported that. This change is just about the Unicode characters allowed in element and attribute names (and entity names and processing instruction targets). I see relatively little use of non-ASCII characters in element and attribute names. A user who is technical enough to deal with raw XML markup can deal with ASCII element/attribute names. For less technical users who want to see element/attribute names in their native language, using native language markup is not a good solution, because it only allows a document or schema to be localized for a single language. An XML editor can provide a much better solution by supporting schema annotations that allow an element or attribute to be given friendly names in multiple languages. So a Thai user editing a document using the schema can work with Thai element/attribute names, and an English user working with the same document can see English names...

Trying to Figure Out Where Open Formula Fits In
Rick Jelliffe, O'Reilly Technical

I've been trying to figure out OpenFormula recently... During the OOXML standardization process, particularly preparations for the BRM, I was impressed by how mission-critical spreadsheets are to industry, but also how users of spreadsheet applications have been like lambs to the slaughter: issues that programmers get taught in their first months, such as accuracy, precision, the nature of floating-point arithmetic, are swept under the carpet by spreadsheet developers. Now it may well be that their users are too unsophisticated to understand these kinds of things, but if the user is making mission-critical calculations where these issues are relevant, that user deserves to be educated. And education relies on the information being public. OpenFormula is an new formula language for spreadsheets, that has come out of the ODF effort at OASIS Open. It has quite few advantages over the Excel spreadsheet language, for example a proper library mechanism. It is supposed to be part of ODF 1.2, but is still at late draft stage. However, it is not syntactically compatible with the Excel formula syntax of IS29500... OpenFormula actually defines an exchange formula language which has explicit delimiters, but also allows (and partly defines) application- specific user interface languages, which allows spaces and other delimiters. This is the way of working around the problem that existing applications have different features and slightly different syntaxes. The separation between formal common interchange notations and friendly front-ends is not new: the browser address bar is a good example, but it is also how localization works... What is required? All spreadsheet implementations need to provide the feature set that supports Open Formula and OOXML: all those functions and library referencing. All spreadsheet implementations that generate ODF need to generate OpenFormula and nothing else inside the ODF. All spreadsheet implementations that generate OOXML need to generate IS29500 syntax and nothing else inside the OOXML. Pollution of ODF or OOXML documents with non-conforming formula should not be tolerated in the name of supporting legacy: these are only a couple of years or so old, for goodness sake. The SC34 group on reconciling ODF and OOXML need to liaise with OASIS and ECMA to try to reduce gratuitous differences...

Public Review of Open Document Format v1.0 Errata
Patrick Durusau (ed), OASIS Public Review Draft

The OASIS Open Document Format for Office Applications (OpenDocument) TC has recently approved an errata document as a Committee Draft and published the package for public review: "Open Document Format for Office Applications (OpenDocument) 1.0 Errata 01 Committee Draft 03." The public review ends November 13, 2008. The errata apply to OpenDocument v1.0, which is identical in the technical content corrected to ISO/IEC 26300. The Open Document Format for Office Applications (OpenDocument) format, is an open, XML-based file format for office applications, based on OpenOffice.org XML. This document is the errata document for for ODF 1.0 and includes references to ODF 1.0 Second Edition (ISO/IEC 26300) and N0492, the Japanese National Body comments provided for the reader's convenience.


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

Headlines

Sponsors