This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation http://www.microsoft.com
- OAuth Web Resource Authorization Profiles
- A SASL Mechanism for OpenID
- OASIS Public Review Draft for Production Planning and Scheduling (PPS)
- W3C First Public Working Draft for Selectors API Level 2
- Open Source Clouds on the Rise
- Heartland Moves To Encrypted Payment System
- IETF Internet Draft on Web Linking Considered as a Proposed Standard
- Microsoft Urges Laws to Boost Trust in the Cloud
OAuth Web Resource Authorization Profiles
Dick Hardt, Allen Tom, Brian Eaton, Yaron Goland (eds), IETF Internet Draft
IETF has published an Internet Draft for OAuth Web Resource Authorization Profiles. The OAuth Web Resource Authorization Profiles (OAuth WRAP) allow a server hosting a Protected Resource to delegate authorization to one or more authorities. An application (Client) accesses the Protected Resource by presenting a short lived, opaque, bearer token (Access Token) obtained from an authority (Authorization Server). There are Profiles for how a Client may obtain an Access Token when acting autonomously or on behalf of a User.
Background: "As the internet has evolved, there is a growing trend for a variety of applications (Clients) to access resources through an API over HTTP or other protocols. Often these resources require authorization for access and are Protected Resources. The systems that are trusted to make authorization decisions may be independent from the Protected Resources for scale and security reasons. The OAuth Web Resource Authorization Profiles (OAuth WRAP) enable a Protected Resource to delegate the authorization to access a Protected Resource to one or more trusted authorities.
Clients that wish to access a Protected Resource first obtain authorization from a trusted authority (Authorization Server). Different credentials and profiles can be used to obtain this authorization, but once authorized, the Client is provided an Access Token, and possible a Refresh Token to obtain new Access Tokens. The Authorization Server typically includes authorization information in the Access Token and digitally signs the Access Token. Protected Resource can verify that an Access Token received from a Client was issued by a trusted Authorization Server and is valid. The Protected Resource can then examine the contents of the Access Token to determine the authorization that has been granted to the Client.
The Access Token is opaque to the Client, and can be any format agreed to between the Authorization Server and the Protected Resource enabling existing systems to reuse suitable tokens, or use a standard token format such as a Simple Web Token or JSON Web Token. Since the Access Token provides the Client authorization to the Protected Resource for the life of the Access Token, the Authorization Server should issue Access Tokens that expire within an appropriate time. When an Access Token expires, the Client requests a new Access Token from the Authorization Server, which once again computes the Client's authorization, and issues a new Access Token... Two Profiles are recommended for scenarios involving a Client acting autonomously: (1) Client Account and Password Profile, where the Client is provisioned with an account name and corresponding password by the Authorization Server; (2) Assertion Profile, which enables a Client with a SAML or other assertion recognized by the Authorization Server...
A SASL Mechanism for OpenID
Eliot Lear, Hannes Tschofenig, Henry Mauldin (eds), IETF Internet Draft
IETF has published an initial -00 version of a specification A SASL Mechanism for OpenID. OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) is an application framework to generalize authentication. This memo specifies a SASL mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL.
Details: "OpenID is a three-party protocol that provides a means for a user to offer identity assertions and other attributes to a web server (Relying Party) via the help of an identity provider. The purpose of this system is to provide a way to verify that an end user controls an identifier.
Simple Authentication and Security Layer (SASL), defined in RFC 4422, is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. SASL is used by application protocols such IMAP, POP and XMPP, with the goal of modularizing authentication and security layers, so that newer mechanisms can be added as needed. This memo specifies just such a mechanism.
As currently envisioned, this mechanism is to allow the interworking between SASL and OpenID in order to assert identity and other attributes to relying parties. As such, while servers (as relying parties) will advertise SASL mechanisms, clients will select the OpenID mechanism. The OpenID mechanism described in this memo aims to re-use the available OpenID specification to a maximum extent and therefore does not establish a separate authentication, integrity and confidentiality mechanism. It is anticipated that existing security layers, such as Transport Layer Security (TLS), will continued to be used... This document requires enhancements to the Relying Party and to the Client (as the two SASL communication end points) but no changes to the OpenID Provider (OP) are necessary. To accomplish this goal indirect messaging required by the OpenID specification is tunneled within SASL..."
See also: the OpenID Foundation (OIDF)
OASIS Public Review Draft for Production Planning and Scheduling (PPS)
Yasuyuki Nishioka, Koichi Wada (eds), OASIS PPS TC Committee Drafts
Members of the OASIS Production Planning and Scheduling (PPS) Technical Committee have released an approved set of PPS specifications for public review through March 12, 2010. This TC was chartered in 2003 to "develop common object models and corresponding XML schemas for production planning and scheduling software, which can communicate with each other in order to establish collaborative planning and scheduling on intra and/or inter enterprises in manufacturing industries."
"OASIS PPS (Production Planning and Scheduling) specifications deal with problems of decision-making in all manufacturing companies who want to have a sophisticated information system for production planning and scheduling. PPS specifications provide XML schema and communication protocols for information exchange among manufacturing application programs in the web-services environment...
PPS (Production Planning and Scheduling) Part 1: Core Elements, Version 1.0 focuses on an information model of core elements which can be used as ontology in the production planning and scheduling domain. Since the elements have been designed without particular contexts in planning and scheduling, they can be used in any specific type of messages as a building block depending on the context of application programs.
PPS (Production Planning and Scheduling) Part 2: Transaction Messages, Version 1.0 focuses on transaction messages that represent domain information sending or receiving by application programs in accordance with the context of the communication, as well as transaction rules for contexts such as pushing and pulling of the information required... PPS (Production Planning and Scheduling) Part 3: Profile Specifications, Version 1.0 focuses on profiles of application programs that may exchange the messages. Application profile and implementation profile are defined. Implementation profile shows capability of application programs in terms of services for message exchange, selecting from all exchange items defined in the application profile. The profile can be used for definition of a minimum level of implementation of application programs who are involved in a community of data exchange..."
See also: the OASIS announcement
W3C First Public Working Draft for Selectors API Level 2
Lachlan Hunt (ed), W3C Technical Report
Members of the W3C Web Applications Working Group have published a First Public Working Draft for the specification Selectors API Level 2. Selectors, which are widely used in Cascading Style Sheets (CSS), are patterns that match against elements in a tree structure...
The Selectors API specification defines methods for retrieving Element nodes from the DOM by matching against a group of selectors, and for testing if a given element matches a particular selector. It is often desirable to perform DOM operations on a specific set of elements in a document. These methods simplify the process of acquiring and testing specific elements, especially compared with the more verbose techniques defined and used in the past...
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing the specification before it eventually reaches the Candidate Recommendation stage should join the appropriate mailing lists and take part in the discussions..."
Open Source Clouds on the Rise
Michael Biddick, InformationWeek
"Cloud computing has the potential to transform how government agencies tap into IT services, and open source is an underlying technology in several of the early government clouds that have been developed... A challenge for government agencies is determining how one cloud can work with other clouds and IT systems to provide the same secure, robust infrastructure that exists with traditional IT environments. Here's where agencies may turn to open source, which has the advantage of 'openness,' providing flexibility, interoperability, and the potential for customization without the risks of vendor lock-in...
Components of the open source software stack that are being used to build and manage clouds include the Linux operating system, Eucalyptus (incorporates the Apache Axis2 Web services engine, Mule enterprise service bus, Rampart security, and Libvirt virtualization), Datacloud, Nimbus' EC2 interface (lets organizations access public cloud infrastructures), virtual machine hypervisors, and Zend Technologies' Simple API (can be used for calling a cloud service from multiple clouds; GoGrid, IBM, Microsoft, Nirvanix Storage Delivery Network, and Rackspace Files all support it).
In an example of how the pieces fit together, NASA's Ames Research Center is using Eucalyptus, the Lustre file system, Django Web application framework, and SOLR indexing and search engine in its Nebula cloud. Standards are still needed to ensure the viability of open source clouds, and reliability and security have to be proven. With those concerns on the table, the gradual adoption of cloud computing, along with open source, is the path we're on. Open source can help minimize up-front investment, give agencies control over their clouds, and tap into shared resources..."
Heartland Moves To Encrypted Payment System
Joab Jackson, Network World
"Responding to its widely reported and massive data breach that took place a year ago, Heartland Payment Systems will be moving to an end-to-end encryption system for payment transactions, according to Chairman and CEO Robert Carr: 'We're using encryption on the front end to keep card numbers out of our merchants' systems, and to also have all the card numbers coming through our network be encrypted throughout, except at the point of decryption'. In January 2009, Heartland Payment Systems reported that it found that intruders had penetrated its systems and planted software to harvest card numbers, using SQL injection attacks to plant programs inside the network that would sniff the card numbers.
Heartland, which handles more than 4 billion transactions annually for more than 250,000 merchants, will be using Thales nShield Connect hardware security module along with Voltage Security's SecureData encryption software as the basis of this capability... This new system involves installing a tamper-resistant security module (TRSM) at the point-of-sale system. When a card is swiped, the TRSM encrypts the card's number with a public key using Identity Based Encryption, and it is sent to the Heartland gateway. This new system will offer merchants the capability to encrypt cards so the merchant themselves will not house the card numbers on their systems at all, explained Terrence Spies, the chief technology officer for Voltage Security. Most merchant payment-processing systems encrypt the PIN number or security numbers of cards. The card numbers themselves aren't typically encrypted at the cash registers, also called point-of-sale systems.
Spies: "The HSM controls the process of decrypting the private key... This system will use a technique called format-preserving encryption (FPE), which means the encrypted numbers will be the same length as the original card numbers, allowing the encrypted numbers to be used in other database systems as identifiers, rather than the original numbers. Heartland piloted a few test systems with merchants last year and now plans to start offering the service to all its customers. Because moving to the card encryption will require purchasing new hardware for the register, Heartland will offer the end-to-end encryption as an opt-in... Carr said that if the merchant implements the system correctly and it then suffers a breach involving the leakage of card numbers, then Heartland will assume the liability for the breach..."
See also: Cryptographic Key Management
IETF Internet Draft on Web Linking Considered as a Proposed Standard
Mark Nottingham (ed), IETF Internet Draft
The Internet Engineering Steering Group (IESG) announced receipt of a a request to consider version -07 of the Web Linking specification as an IETF Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action through 2010-02-17.
This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header-field.
Background: "A means of indicating the relationships between resources on the Web, as well as indicating the type of those relationships, has been available for some time in HTML, and more recently in Atom (IETF RFC 4287). These mechanisms, although conceptually similar, are separately specified. However, links between resources need not be format-specific; it can be useful to have typed links that are independent of their serialisation, especially when a resource has representations in multiple formats. To this end, this document defines a framework for typed links that isn't specific to a particular serialisation or application. It does so by re-defining the link relation registry established by Atom to have a broader domain, and adding to it the relations that are defined by HTML.
Appendix E (Document History) in this 25-page document lists some sixteen (16) changes since the publication of version -06 (20 pages): Allowed multiple spaces between relation types; Relaxed requirements for registered relations; Removed Defining New Link Serialisations appendix; Added Field registry; Added registry XML format; Changed registration procedure to use mailing list(s), giving the Designated Experts more responsibility for the smooth running of the registry; Loosened prohibition against media-specific relation types to SHOULD NOT; Disallowed registration of media-specific relation types—can still be used as extension types; Clarified that parsers are responsible for resolving relative URIs; Fixed ABNF for extended-initial-value; Fixed 'title*' parameter quoting in example; Added notes for registered relations that lack a reference; Added 'hreflang' parameter; Clarified status of 'rev'; Removed advice to use '@profile' in HTML4; Clarified what multiple '*title' and 'hreflang' attributes mean...
See also: the comment archive at W3C
Microsoft Urges Laws to Boost Trust in the Cloud
Lance Whitney, CNET News.com
Microsoft is so concerned about the future of cloud computing that it's urging the government to step in. In a speech Wednesday [2010-01-20], Microsoft general counsel and senior vice president Brad Smith called on government and business to shore up confidence in cloud computing by tackling issues of privacy and security—two major concerns that have been voiced about the cloud...
A Microsoft survey found that 58 percent of the public and 86 percent of business leaders are excited about the possibilities of cloud computing. But more than 90 percent of them are worried about security, availability, and privacy of their data as it rests in the cloud. Microsoft said it also found that most of the people surveyed believe the U.S. should set up laws and policies to govern cloud computing...
During his speech, Smith proposed that Washington create a Cloud Computing Advancement Act that would protect consumers and give the government tools to handle issues such as data privacy and security. He added that an international dialogue is crucial in addressing data security so that information is protected no matter where it resides. In proposing legislation, Microsoft is looking to the government to enact specific measures, including to: (1) Beef up the Electronic Communications Privacy Act to more clearly define and protect the privacy of consumers and businesses; (2) Update the Computer Fraud and Abuse Act so that law enforcement has the resources it needs to combat hackers; (3) Establish truth-in-cloud-computing principles so that consumers and businesses know how their information will be accessed and secured; (4) Set up a framework so that differences in regulations on cloud computing among various countries can be better clarified and reconciled...
See also: the CommVault survey on cloud use
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/