Security concerns, especially since the events of last Fall, are at
the center of many industry discussions. Ever-increasing reports of
hacker activities and security holes in well-known software products
further fuel the debate, and rightfully so.
Web services is a great new technology that will form the
underpinning for electronic business of the future. So making Web
services secure should be, and is, one of the activities our industry
needs to focus on most. Beyond the very basic aspects of security,
reliability, authentication and nonrepudiation issues, however,
another related issue also deserves to be looked at: trust.
Security, Trust, Web Services, and E-Business
Trust will in my view be a critical factor in the further adoption of
Web services. When I say trust, I really mean more than just trust as
"created" through various security technologies. Rather, what I mean
is trust much more in the ordinary sense of the word.
A World of Web Services
Built on TRUSTe?
To find a past case where trust issues and information technology
intersected, we have to look no further than at the early days of the
Internet and Web-based commerce. As detailed in the Online Privacy
Resource Book published by the not-for-profit organization TRUSTe
(www.truste.com ), issues around trust deficiency and its role as a
potential inhibitor to building a worldwide electronic community of
open business relationships were already identified in the very early
days of the Web.
In the world of TRUSTe, a program designed around the philosophy of
self-governance, four core requirements form the basis for its rules
and procedures:
- Notice: A Web site must declare what kind of information will
be gathered about a user
- Choice: A user's ability to freely permit (or not to permit) data gathering
- Access: A user's ability to verify what data has been collected
and ensure its accuracy
- Security: The guarantee that a user's data is collected and stored
in a secure manner
In the future, in the ultimate world of dynamic business webs, we'll
see Web services- based agents dynamically publish, discover, and
integrate services from third parties around the globe. Many of these
services may be provided by previously unknown (and also very often
hidden by the user) service providers. Since all the actions of these
agents are done on behalf of the user or corporate entity, the exact
same challenges encountered by online commerce will also be faced in
dynamic business webs. And similar solutions may apply as well.
In the world of TRUSTe, a Web site posts a logo on its pages that
indicates that the operating company has a contractual relationship
with TRUSTe and that it follows TRUSTe's policies on privacy and
conflict resolution. Similarly, we may now see Web services provide a
digital credential that would indicate to a service consumer that it
follows similar policies and procedures for trusted Web services.
Components of Trust Certificates
For the purpose of this discussion, let's call these certificates
"trust certificates" and see what some of the potential components
for trust certificates could be, and how and where trust certificates
would be used.
No Trust Without Security
The fourth pillar of TRUSTe's policies, security, would certainly be
at the core of any trust certificate. Security is very broad
discipline and involves diverse and plentiful challenges, but the
different standards and specifications that address them are equally
numerous. Indeed, many technologies in this area have either been
developed already or are being developed as I write.
To secure the communication between a Web service and its clients, we
can use the infrastructure already developed for the "old" Internet -
for example, HTTP over SSL (Secure Sockets Layer) or more recently
TLS (Transport Layer Security) for secure data transfer (see Figure
1). HTTP Basic Authentication, to authenticate users, or rather user
agents, has also been with us for quite some time now (for too long
many security experts would probably argue).
Figure 1:
In the new world of Web services and SOAP, many new and important
specifications are being developed. SOAP DSIG (Digital Signatures) is
an important, more recent, specification that describes how SOAP
messages (or parts thereof) can be digitally signed in order to
ensure the integrity of a message. Furthermore the multiparty nature
of SOAP message routing will require approaches that allow us to
encrypt parts of the message while leaving other parts in plaintext.
If we go beyond these still very basic protocols and specifications,
we find OASIS's XACML (eXtensible Access Control Markup Language).
The goal of the XACML technical committee is to develop "an XML
schema for representing authorization and entitlement policies." Also
at OASIS, we find SAML (Security Assertions Markup Language). One of
the problems SAML will help us solve is nothing less than the issue
of single-sign-on across (potentially) hundreds of thousands of
services around the world.
A Web service's compliance with one or more of these specifications
would represent a big portion of a trust certificate.
Policies for Data Collection
Whenever services communicate, an exchange of user-specific (or
corporation-specific) information will be necessary. Who controls
this process will be as important an issue for dynamic business webs
as it already is for Web sites (see again TRUSTe) and providers of
Internet-wide single sign-on services and identity management such as
the Liberty Alliance (www.projectliberty.org) and Microsoft's .NET
Passport (www.passport.com/).
In the world of Web site and Intranet security, it's becoming common
to go beyond simple access control lists (ACL) and to protect and
manage access to resources via policies that specify what actors are
allowed to do - e.g., read a file - and under what conditions. For
the purposes of Web services, we may choose to follow a similar
approach and express policies that specify what data will be exposed
to specific groups of services. One example would be to be very
restrictive with "untrusted" service providers and to expose more
information to properly authenticated and trusted services.
Service Quality and Reliability
As we're building distributed applications and forming dynamic
business webs we may - by definition - use services outside of our
control. The questions then become: how reliable is the service we're
using and what service level can the provider of a service guarantee?
Service Level Agreements (SLAs) and their negotiation and execution
in traditional IT is already challenging enough, but in a world of
dynamic binding of services we'll have to find electronic means to
express metrics and commitments as to the quality of the services
offered. As a developer, I wouldn't trust a service to the extent
that I'd integrate it into my software unless I could receive certain
guarantees about the performance and availability of that service.
(One could also envision that SLA negotiation could be tied to the
billing service, so a service provider and client could automatically
negotiate a certain level of service for a certain fee.)
A Bullish Future
The Business Software Alliance (www.bsa.org) has conducted a survey
of the CEOs of its member companies. According to this survey, the
group is very bullish about the future of security technologies,
going as far as stating that "concerns about the security of Internet
transactions would largely be resolved by 2005." Let's hope so.
Usage Models
for Trust Certificates
Trust certificates could be part of the many diverse components that
form the necessary framework for electronic collaboration between
business partners. The electronic business initiative ebXML
(www.ebxml.org) - jointly sponsored by OASIS and UN/CEFACT - has put
a lot of thought into how trading partners can describe their
individual preferences and capabilities and how two parties can use
these descriptions to come to individual agreements.
EbXML introduces the two concepts of CPPs and CPAs. A CPP is a
"collaboration protocol profile" and describes the technical
capabilities of a particular party. These records include information
about supported transport protocols, security requirements, and
messaging capabilities, as well as references to applicable business
processes. A CPA, or "collaboration protocol agreement," is formed
when two parties (or rather the automated agents representing these
parties) agree on the individual technical parameters for this
particular business interaction.
I could see trust certificates becoming yet another component that a
CPA would reference or contain. When an automated agent searches for
a suitable service provider (based on business and technical
parameters) it could also check a particular party's trust
certificate and, for instance, filter out services that don't follow
the required trust and privacy guidelines.
Trust certificates could also play a role in registry and repository
infrastructures such as UDDI, the Universal Description Discovery and
Integration initiative (www.uddi.org). UDDI uses the tModel concept,
in which a tModel is essentially a pointer to a particular technical
component of a service - for instance, a WSDL file.
In the future we might see trust certificates being registered with
UDDI as a particular tModel and being used via UDDI search-APIs to
find services suitable for consumption.
Figure 2:
Trust Beyond Web Services
One industry that's been plagued by issues around trust,
confidentiality, and security is the electronic marketplace. Besides
business issues such as lower margins and the fear of
commoditization, trust-related concerns are listed as one of the top
factors that hinder the adoption of e-marketplaces.
As we're trying to increase operational efficiencies throughout the
supply chain, providers of products and services are often required
to share more and more information considered sensitive and
business-critical in nature. Very often companies choose not to
participate in collaborative commerce networks and marketplaces
because to do so would require them to make public information - such
as inventory levels, forecasting information, and pricing - that
they'd rather their competitors didn't see. The Alliance for
eCommerce Trust (www.eyquem.com) has put together a very informative
and detailed compendium about trust and B2B. (I also have the
pleasure of serving on the advisory board of that group.)
Trust certificates, as proposed in this article, could be a step
toward making electronic marketplaces and collaborative commerce
initiatives more appealing to all participants.
Figure 3:
Future Opportunities
Certification Authorities
Just as TRUSTe and other such initiatives play the role of a trusted
party in the world of online commerce, certificate authorities play a
similar role in the world of encryption and digital signatures.
Should the idea of trust certificates ever become a reality, then
there's an opportunity for enterprises that offer services such as
policy development, certification, monitoring, and dispute resolution.
Intermediaries
A third party may start to act as an intermediary that offers
services for service providers and service clients alike. Examples of
these services are payment processing, hosting of registries, and
maybe even quality control of the Web service interfaces they host
and manage on behalf of the actual provider of the service. Some of
these intermediaries may then emerge as "places to go to" in order to
find Web services that can be "trusted."
Even without explicit trust certificates, certification authorities,
and intermediaries, the issue of trust may be addressed in different
ways. Some companies will simply become "trusted" parties and
services providers because of their consistent high standards and the
brand associations they develop around these standards.
Value-Added Registries
While registries for services such as UDDI certainly provide a
valuable infrastructure for service management, I can also see
value-added registries that not only contain pointers to service
providers but also monitor them (e.g., their up- and downtime) and
track how many service consumers have engaged in long-term and/or
short-term integration with a particular service. While certainly
this in itself creates many questions about privacy and
confidentiality, this approach would use group behavior to derive
trust-related information. In other words, if a million consumers
bind to a particular service A compared to 10 who bind to service B,
you may derive (subjective) trust assumptions from that - such as, if
a million entities trust them, why shouldn't I. . .?
Summary
Security and trust will be concerns that will remain hot topics for
many years to come. To begin with, every potential provider of Web
services should start thinking about how they can increase the
trustworthiness of their service offerings.
Author Bio
Norbert Mikula is industry editor of Web Services Journal
and has more than 10 years
of experience in building and delivering Internet and e-business
technologies. He serves as
vice-chairman of the board of directors of OASIS, is recognized
internationally as an expert in Internet and e-business technologies,
and speaks regularly at industry events.
norbert@sys-con.com
