This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com
- NIST Releases New XML Schema Quality of Design (QOD) Tool
- W3C Call for Implementations of CSS Namespaces Module Specification
- What Social Networks Are Teaching Us About Data Portability
- Fedlet: Lightweight Service Provider Implementation of SAML2 SSO Protocol
- IBM Pushes Federated Identity Management
- DKIM Author Domain Signing Practices (ADSP)
NIST Releases New XML Schema Quality of Design (QOD) Tool
Staff, NIST Announcement
The U.S. National Institute of Standards and Technology (NIST) has announced a new release of the XML Schema Quality of Design Tool (QOD) from the Manufacturing Engineering Lab. "QOD assists in consistently using XML Schema for the specification of information. QOD is intended for both people developing guidelines for writing high quality XML schemas and those writing XML schemas. The purpose of QOD is to improve the quality of the XML schemas. The system allows users to define rules for writing quality XML Schemas and to test schemas against those rules. This release of the tool includes improvements to the user interface, performance, and display of results, support for ISO Schematron for writing tests, and the addition of an import and export capability to facilitate offline development of tests. The QOD site also contains a number of sample sets of tests for XML Schema Naming and Design Rule (NDR) specifications. In addition to the improvements to the tool, the number of tests available also has been expanded. Extensive sets of test based on the following specifications are available: (1) The OAGIS 9.0 XML Naming and Design Rules Standard; (2) IRS XML Standards and Guidelines; (3) Department of the Navy XML Naming and Design Rules. As a guest user, you may use these rules to check whether a schema that you are developing or uses meets those guidelines. More advanced users are able to create their own rules and make sets of rules available to their communities." Several of the XML Naming and Design Rules specifications in use are derived from work pioneered in the OASIS Universal Business Language (UBL) Technical Committee and the UN/CEFACT Forum. Together with the OASIS UBL NDR specification, the UN/CEFACT NDR document is one of the foundational NDRs developed in accordance with the UN/CEFACT Core Components Technical Specification (CCTS).
See also: Naming and Design Rules specifications
W3C Call for Implementations of CSS Namespaces Module Specification
Peter Linss and Chris Lilley (eds), W3C Technical Report
Members of W3C's Cascading Style Sheets (CSS) Working Group have published the Candidate Recommendation for the "CSS Namespaces Module" specification. A W3C Candidate Recommendation is a document that has been widely reviewed and ready for implementation; W3C encourages everybody to implement this specification and return comments to the archived public mailing list. The CSS Namespaces module defines syntax for using namespaces in CSS. It defines the '@namespace' rule for declaring a default namespace and for binding namespaces to namespace prefixes. It also defines a syntax for using those prefixes to represent namespace-qualified names. It does not define where such names are valid or what they mean: that depends on their context and is defined by a host language, such as Selectors, that references the syntax defined in the CSS Namespaces module. Note that a CSS client that does not support this module will (if it properly conforms to CSS's forward-compatible parsing rules) ignore all '@namespace rules', as well as all style rules that make use of namespace qualified names. The syntax of delimiting namespace prefixes in CSS was deliberately chosen so that these CSS clients would ignore the style rules rather than possibly match them incorrectly. A document or implementation cannot conform to CSS Namespaces alone, but can claim conformance to CSS Namespaces if it satisfies the conformance requirements in this specification when implementing CSS or another host language that normatively references this specification. For this specification to exit the CR stage, three conditions must be met: (1) There must be at least two interoperable implementations, as defined in the document; (2) A minimum of another three months of the CR period must elapse, viz., this specification will not exit CR before 23-August-2008; (3) The specified technology must not be judged harmful for accessibility. A CSS Namespace Test Suite is being developed during the Candidate Recommendation phase.
See also: Cascading Style Sheets Current Work
What Social Networks Are Teaching Us About Data Portability
Steven Robbins, InfoQueue
As more social networking sites are popping up, the questions around the data they keep are rising. Data portability has become the watch phrase across the Web 2.0 world. Is there something to be learned about data access and portability from these services? Several of the major Web 2.0 players and services have made announcements about making the data they store "available" to the users who own it or aggregating access to data from other services. MySpace, Yahoo, eBay, Twitter, and Photobucket agreed to a partnership under the MySpace Data Availability initiative. Facebook announced their Facebook Connect technology to allow members to access their profile data from places other than Facebook. Google launched the preview release of Friend Connect that will allow users to see and interact across several social networks. Friendfeed released an API to allow programatic access to their multi-site aggregation capabilities. In the background, but moving to the forefront, The DataPortability Project has been bringing together partners, technology, principles, and practices to make data portability and ownership a priority and an achievable goal... Among the main technologies that the Project focused on were OpenID, OAuth, RSS, OPML, microformats, RDF, apml, and XMPP. While these technologies have been strongly tied to social networking, they have also been picking up usage in other areas as well. OAuth has been making inroads with Google Data APIs and Yahoo Fire Eagle API. Spring Security (Acegi) added OpenID support. Most all of the major browsers have already added or announced microformat support of one kind or another... The more that Software-as-a-Service and cloud computing are picked as enterprise and application models, the more distributed systems become. The distribution can lead to much more decentralization, even beyond the enterprise/organizational boundaries. This can be seen in healthcare with the rise of the Personal Health Record (PHR). With names like Google and Microsoft announcing PHR offerings over the web, data portability and availability will start hitting home with many more people than just those on social networking sites. From the DataPortability Project web site: [the project seeks to] "(1) promote the philosophy and data portability ethos in the marketplace; (2) promote the use of existing standards that enable data portability; (3) encourage the development of those standards in ways that facilitate data portability; (4) engage with individuals, services and standards bodies with similar views where their scope is relevant; (5) identify new standards that are required to fulfill the data portability vision."
See also: The DataPortability Project
Fedlet: Lightweight Service Provider Implementation of SAML2 SSO Protocol
Sidharth Mishra, Blog
"Fedlet is a lightweight Service Provider implementation of SAML2 SSO protocols, embeddable in a Java EE web application. Fedlet is a new feature, which will be part of upcoming Sun Federated Access Manager (OpenSSO) release. Fedlets are extremely light weight, and they can be easily embedded into a Service Provider application, and enable it to accept SAML POST from an Identity Provider, and use that to pull user attributes into the Service Provider application. The user attributes are part of the SAML Response from the IDP, that the IDP sends to the Fedlet, once an user successfully authenticates at the Identity Provider. Fedlets have many interesting usage in Federation scenarios such as: (1) Quick federation enablement of Service Providers, which allows Identity Providers to make them a part of their business circle of trust in no time and to use their feature Offerings. (2) Federation enablement at minimal cost and minimal investment in hardware and services. (3) Support minimal SSO related needs in business scenarios, without the need for a full fledged Federation product/solution deployment. A screencast on Fedlets is available, covering business usage scenario, process flow and some Frequently Asked Questions ... Federated Access Manager / OpenSSO, is a self-contained J2EE application, which can be deployed on J2EE containers. Federated Access Manager(FAM) introduces a workflow centric approach which makes installation, deployment and administrative tasks simpler, quicker, and easier. The goal has been to make the product really simple to use and configure, for real time production deployments in different areas such as Federation management, Agents Management, Web Services Security etc. and we're making progress... Paul Madsen had asked: "If you control the technology at both the IDP & SP ends, the fact that both ends use a standard for messaging and assertions is irrelevant isn't it? Would the fedlet, once deployed by an SP, be reusable with other IDPs (than the one that created it initially) and thereby be considered a quick and easy way to SAML enable an SP..." to which Pat Patterson replied: "It could indeed be reused with other IdPs. The Fedlet is configured via SAML 2.0 metadata, saved to a directory on disk. The very first time you visit the Fedlet's deployment URI, it offers to save configuration to disk... At this point you can expand the Fedlet WAR manually and copy the files yourself, or let the Fedlet do it for you. In either case, you can edit the SAML 2.0 metadata to use any SAML 2.0 identity provider (or providers). OpenSSO even includes an 'unconfigured' Fedlet for doing this all completely manually... So, yes, the Fedlet is a quick and easy way to SAML enable an SP!"
See also: Pat Patterson's blog
IBM Pushes Federated Identity Management
Brian Prince, eWEEK
With Version 6.2 of its Federated Identity Manager, IBM brings multiple identities into a centralized system. IBM is pushing interoperability as a solution to enterprise identity management and authentication woes. In Version 6.2 of IBM Tivoli Federated Identity Manager, the company has integrated a number of user-focused identity management technologies and frameworks, including OpenID, Microsoft Windows CardSpace, and the Eclipse Higgins identity framework. In addition, the software now supports a wide range of user and application credentials such as RACF (Resource Access Control Facility) PassTicket, Kerberos, SAML (Security Assertion Markup Language), Web Services-Security and platform-specific credentials used by Microsoft .Net, IBM WebSphere, SAP NetWeaver, Oracle, and CA. The idea, IBM officials said, is to bring multiple identities into one central, federated identity management system that supports both legacy and newer user-centered frameworks. IBM is also targeting SOA with this release by including a built-in SOA Identity Service to enable users to validate, manage and audit identities across a variety of formats and vendors' applications to help maintain identity context. IBM is one of the leaders in the identity and access management market in terms of revenue. According to IDC analyst Sally Hudson, the company has both the technological expertise and the resources necessary to pull off this concept for customers. Hudson explained that a federated ID environment requires companies sell the idea internally and then externally to partners and contractors, reassuring all involved that this will not reduce security and raise risk. Afterward, organizations must evaluate their architectures and the different points of interaction and integration. Joe Anthony, program director for security and compliance management with IBM Tivoli: "We now make it much easier for someone to deploy our federated identity access manager with other access management products that are in the marketplace, and that only just makes it easier for a customer to go ahead and deploy that into their environment."
See also: Federated Identity Manager
DKIM Author Domain Signing Practices (ADSP)
Steve Atkins, Jon Callas (et al., eds), IETF Internet Draft
This document specifies an adjunct mechanism to aid in assessing messages that do not contain a DKIM signature for the domain used in the author's address. It defines a record that can advertise whether they sign their outgoing mail, and how other hosts can access those records. DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. However, the legacy of the Internet is such that not all messages will be signed, and the absence of a signature on a message is not an a priori indication of forgery. In fact, during early phases of deployment it is very likely that most messages will remain unsigned. However, some domains might decide to sign all of their outgoing mail, for example, to protect their brand name. It is desirable for such domains to be able to advertise that fact to other hosts. This is the topic of Author Domain Signing Practices (ADSP). Hosts implementing this specification can inquire what Author Signing Practices a domain advertises. This inquiry is called an Author Signing Practices check. The basic requirements for ADSP are given in "Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol" (RFC 5016).
See also: IETF Requirements RFC
XML Daily Newslink and Cover Pages are sponsored by:
|BEA Systems, Inc.||http://www.bea.com|
|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/