GSA
Headquarters
18th
& F Streets, N.W, Room 5141
Washington
DC 20405
Please send all
comments or corrections to these minutes to Glenn Little at glittle@lmi.org.
Mr. Owen Ambur: Lisa [Weber] said there are more people at the door, so I think they’ll be dribbling in. Our first speaker, Phillip Hallam-Baker, has to leave shortly after his presentation, so let’s go ahead and get started. We usually start with introductions, so let’s go around the room and introduce ourselves. If you’ve not been here before, perhaps you can give us a quick word on your interest in XML. I’m Owen Ambur of the Fish and Wildlife Service, and I’m co-chair, along with Marion [Royal], of this Working Group.
[Introductions]
Mr. Ambur: I’ve heard several clicks on the phone. Would whoever is joining us by teleconference care to introduce yourselves?
[Telephone participant introductions]
Mr. Ambur: We’ll give the folks who come in later a chance to introduce themselves at the break, so let’s go ahead and get started.
Our first speaker is Phillip Hallam-Baker of VeriSign, here to talk to us about Web Services, so Phillip, the floor is all yours.
Dr.
Phillip Hallam-Baker
VeriSign
Without
Security, Web Services Are Dead On Arrival
Thank you. Well, a little
about myself. I’m Phillip Hallam-Baker. I’ve been working on the Web Services
specification for about three years.
The Web Services pieces
we’re talking about here are designed to be part of the infrastructure—to be
embedded in all products, not proprietary. DoD [Department of Defense] does Web
Services, and they have their own niche needs, etc. We’re not just talking
about a technology we want you to use; we’re going to hear from DataPower on
this same subject, and we have a product as well, but we’re talking about the
landscape of Web Services.
Slide 2 [Walking the Walk…VeriSign and Web
Services]: The way I got into this was from a user’s perspective.
I’ve been in the business for seven years. It was all coding from day one—C++
or Java. Single hardware vendor; a monoculture. You think, “What’s that got to
do with us and our legacy systems, etc.?” The thing is, we’re not talking about
a startup, which then exists independent of other businesses. You acquire or be
acquired, and one business merges into the next, so we have a heterogeneous
infrastructure—so pretty soon, regardless of your start or initial makeup,
everyone has the same sort of integration problems.
Slide 3 [Web Services is about:] Web Services
are all about efficient integration; linking to legacy systems without having
to do a lot of programming or reconfiguration.
It’s not COBOL all over again. Take a legacy system; legacy means “it
works, and people use it.” If you have
to take the legacy system and move to something else, your legacy system
manager says, “Hold it right there! You’re not going to move our system until
you can add value.”
The idea is to leave the
data where they are and add interfaces and standards, so that any platform you
work on, whether it’s Windows NT or VM 3060 or VMS, will have some sort of
system that wraps around whatever you’re talking about. Then we can talk about
Web Services. It’s all about automating the supply chain, but in a way that
doesn’t require you to “drop everything” and start all over again with your IT
infrastructure.
From the commercial side, this
is driven by IT infrastructure. Since we’re in GSA, I imagine there’ll be
pieces of government infrastructure. We’re talking government services, instead
of them building IT infrastructure for themselves. That’s sort of our view. I
must emphasize that there are other views; some others are also right. It’s a
very big field. We need to give our view on the security field.
Slide 4 [Example: Common Interface to Legacy
Systems]: Let’s say you’re running three different security services—a
Merchant Gateway, a Wire Transfer Gateway, and a Billing Service. You want a
common interface for customers, so they say, “Here’s a payment; charge it to
the credit card, bill and send a letter to the customer, follow it up with
collection,” or whatever. You want a single interface. In the old days, you’d
write a single infrastructure. With Web Services, it’s all in a ready-built
took kit, and the standards are specified, so you can build the interface from
standard components, with a standard token for each of the blocks.
Slide 5 [Software Industry Strategy]: So we want
security to be part of this same story. The reason it’s critical for software
is that for 30 years we’ve had one key strategy that’s worked, which is “Sell
more copies than the competition,” so then you have more money for research,
you can reduce the price, sell more copies, and have more money for research,
etc. All the time, software was pushing this strategy, and the prices were
going down. 20 years ago it was $20,000 for a word processing program. Now at
any software store, for $200 you can buy one that doesn’t even fit on a CD.
You’re buying a dictionary equivalent for $200, so if a software company wants
to make a business out of software, how do they do it? Customers are looking at
the total cost of ownership. The only way you can do it is to look at the total
cost to the customer. At the enterprise legacy level, installing it into the
customer’s system is a major part of the cost. We need a solution that sells
software as a service, where we can amortize the development and maintenance
costs.
Slide 6 [Objective]: So we want
Web Services to be like email, where anyone can send to anyone. In the old
days, we needed a gateway; today it’s pretty simple, so even if there are X400
systems, around, users don’t need to know. They don’t need to know whether it’s
Lotus Notes or Exchange. They don’t want it to be like power cords. I usually
carry six of these [power cords]. They all do the same thing: convert AC into
DC. I have one for my PDA [Personal Digital Assistant], one for Blue Tooth, for
my laptop, etc. I don’t want that, because if every Web Service requires its
own maintenance, we’re back in the days of doing niche solutions. We don’t get
the cost savings that standards provide us.
Slide 7 [And Security?]: So what’s the
security angle? We don’t want it doing something like cords catching fire. It’s
not about what systems do. It’s about, “I don’t want it to do something
unexpected.”
Slide 8 [Why Security is Needed]: The reason why we need security is because IT
managers are not allowed to take technology beyond the firewall unless they
have a solid security story—where they can let one company in one location talk
to one in another without configuring every relationship, and without configuring
IT and “Legal.” Remember that before we could do EDI, we had to do an
interchange agreement, with thousands of dollars of configuration costs and
legal fees. We can’t have that.
Slide 9 [Web Services Security
Groups]: There are lots of security groups in
existence. There are two sets: W3C [World Wide Web Consortium (http://www.w3.org/) ] and OASIS [Organization for the
Advancement of Structured Information Standards (http://www.oasis-open.org/home/index.php)].
There’s no rational difference between the two. W3C didn’t have enough slots to
develop as many specifications as were wanted, so they work with OASIS. [Dr.
Hallam-Baker spent a moment describing the work of each of the two groups.]
OASIS has six groups on Web Services security, with probably three in
formation. The point here is that, yes, there are a lot of moving parts and
interconnection. However, we’re all talking. We don’t want one monolithic
scheme like OSI [Open Source Initiative (http://www.opensource.org/)],
where we start a working group, and 10 years later we come out with a standard.
People don’t like that. XML Encryption took about two years; the next was 18
months. SAML [Security Assertion Markup Language (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security)]
took about a year. WSRP [Web Services for Remote Portlets (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp)]
came out about nine months ago, and they just did interoperability testing in
San Francisco.
Mr. Ambur: Do you plan
to talk more about OASIS?
Dr. Hallam-Baker: Yes. [Dr.
Hallam-Baker mentioned XrML [eXtensible rights Markup Language, (http://www.xrml.org/)] and XACML eXtensible
Access Control Markup Language (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml)],
which are cited in Slide 17: They both address authorization policy. There’s
something of an independent battle there. There’s only one part, and the reason
why they’re having the battle is, it doesn’t affect the interoperability story.
Slide 10 [The Problem]: In the old
world, we had tight coupling between client and server applications. In Web
Services, we have a remote procedure call. Instead of these two machines being
the same, they’re now different, so it goes over the Internet or a network
inside the company, and it has some subtle pieces to introduce. In the old
world, the application and subroutine were in the same operating system. In the
new world, we have two operating system contexts, and this piece going over the
network you can’t trust. Our experience is that a system that starts behind the
firewall pretty soon moves beyond it, because it’s more interesting talking to
others than to yourself.
Mr. Ambur: Another point
-- and I don’t know who put determined it but I suspect it is generally true --
is that 80% of the risk ocurs inside the firewall. A good current example of
that is Enron.
Dr. Hallam-Baker: I agree
wholeheartedly. It’s like security guards on the gate: it’s a useful role, but
if you’re serious about getting a gun in here, you can work out a way around
it. It’s all about having to have security measures in place. There are
security vulnerabilities behind the firewall, as well. It’s like the “Great
Wall of China effect”. It encloses a pretty large volume. You have a third of
the world’s population inside, and two thirds of the population outside. Where
do you think the threat is?
What we’re doing in
standards is, we’re logically going to an application context and a remote
context. The main thing is that there’s consistency. If you have two different security
contexts, an attacker can take advantage of the differences between them.
Slide 11 [What Parts of Web Services Security Should
Be Infrastructure?]: We ask the question, “What part should be
infrastructure, and what part should the individual applications solve for
themselves?” because we want a security architecture that’s concise—not like
Encyclopaedia Britannica, where it’s something so complex and onerous that
people don’t want to use it. We’re looking at replicating security facilities
that are already there, that programmers take for granted, because once you
take it for granted, you can never deprogram and thereby get them suspicious.
In a traditional system, you prevent modification of process state,
interception of function calls, and disclosure. What we’re working on is
replicating that part of the Web Services world.
Slide 12 [Is SSL Enough?]: You’ll be
familiar with the SSL [Secure Socket Layer] protocol. In the standards world,
it’s no different. The question is, “Is SSL enough?” For some, yes. When we
started two years ago, we ran over SSL. We still do today, because it does
request/response. It’s not a supply chain application, where data go from A to
B to C to D, but if we want something else, it doesn’t work. If we only have SSL
available, the security story severely limits what Web Services can do. We
won’t be able to protect data in storage; only transit. As you pointed out
earlier, it’s not just the wires that are the problem. If you have lots of
protected information, attackers will try to get it. It’s like with credit card
theft. The problem is not the wires; the problem is employers leaving it
unencrypted, and your identity is now stolen.
Slide 13 [Routing]: Another issue is what to do
with SOAP. SOAP supports message routing. Enterprise A talks to enterprise B.
There’s going to be some border between the enterprise network, the Internet,
and the network of the target enterprise. So what we want to do is, route the
message through the firewall. With traditional protocols, firewalls are limited
in what they can do, like stop communication from going in the wrong direction,
or prevent spoofing attacks from happening. All the data are usually encrypted.
With Web Services, we want to have the option of exposing sufficient information
to the trust gateways so they can make reasonable decisions about allowing data
through or not. It’s all about empowering trust gateways. VeriSign has a
product, and other companies do as well.
With SSL, we see the
encryption bits, but we don’t know anything. Someone could be surfing the Web, moving money, or disclosing
confidential information.
Mr. Bob Benedict: Are you
talking about performance considerations?
Dr. Hallam-Baker: The talk I
give is on standards. I don’t address specific products.
Mr. Benedict: Whether
performance is well supported by that kind of thing?
Dr. Hallam-Baker: People are
using this technology. Performance is not an issue. We have a technology that
can speed up transactions. It’s not the XML piece that’s the problem, it’s the
cryptography. If you buy an accelerator board, you can make it fast enough.
It’s an interesting question though. People used to say they were serious about
security. They’re really serious when they talk about performance.
Slide 14 [WS-Security]: So with the
introduction and framing over, let’s talk about applications. First is Web
Services security. In OASIS, they’re providing security at the SOAP message
level, providing confidentiality and enhancements to the individual message,
not conversations. It requires a response. Just the individual message. It’s
built on XML standards, and signature standards built by W3C. It’s currently in
the final stage of standardization. You can use any security—Kerberos or
whatever—to establish it.
Slide 15 [WS-SecureConversation]: What’s in the
proposal stack is to have a device talking to a service. Imagine if you have
two requests: first, “Is my credit worthy (from Mr. Mallet)? The answer is no.
But Alice is credit worthy. How does Mallet get himself credit worthy? He cuts
and pastes. He takes the Mallet question and pastes it to fool the device to
make it think the response is yes. It’s a response-substitution method. The
response was there, but it came from a different question. It’s clearly bad, and
the Web Service Secure Conversation is what we have to stop it.
Slide 16 [WS-Policy, WS-PolicyAttachments,
WS-SecurityPolicy]: We have a device talking to a service on
some standard, and the service says, “Yes I speak that.” That’s not enough for
the device. It needs to know which version, and which options are available.
With XKMS [XML Key Mangement Specification (http://www.w3.org/TR/xkms/)],
we have something like five options. That’s a simple stack. You have, “Do you
support key recovery, roaming?” You need to know the options; which encryption
algorithms are supported or required. Knowing we have a standard is not enough.
We need to know the options within.
Slide 17 [Part III - Web Services Infrastructure
Security Applications]: The standard defined by WSDL [Web Services
Description Language (http://www.w3.org/TR/2001/NOTE-wsdl-20010315)]
and Web Services policy is an enhancement on the language that allows you to
describe specific options. A security policy allows you to describe options
relating to security. What we’re getting away from is bringing the partner in
and linking to your infrastructures. You don’t want your IT guys and their IT guys
to spend a week figuring out the protocols. You say, “This is my requirement,
and you have to talk this for us to communicate.”
Slide 18 [XML Key Management Specification (XKMS)]: So we’ve
discussed infrastructure. It’s part of the stack. Lets look at the
specifications built on that. These are Web Services that provide a security
service. Web Services can provide any software service; these are specific
security services. This was the first one that Web Services put into a
standards body. When Web Services came along, they said, “We’re not thinking
about security.” Actually, Microsoft came to us and said, “We’re doing Web
Services, should security be built in?” We said, “No, put it in afterward.”
You put in a user name and
password when you’re talking PKI [Public Key infrastructure]. Security is let
in afterward. XLMS is a manager of the public key, because all you need to do
something securely is know the public key. One allows Alice to register;
another allows Bob to look it up. “Public and private” is the way to look at
it. We’re trying to shield the client from the complexity of PKI. We had
complaints that it was too complex for handheld devices.
Slide 19 [Traditional PKI]: Alice wants
to talk to Bob. She goes to an X.500 directory, pulls information from the
directory, then does ASN1 and PKIX. We’re talking about 3/4 of a megabyte.
Alice sends a certification to Bob, and Bob does a dance on his side. The idea
with XLMS is, “Take the complexity of PKI out of the client.” Put a small Web
Services client in there; it talks to the XKMS service, which does the
complexity. You’ll notice Alice talking to Bob, but Bob is using traditional
PKI infrastructure. It’s all backward compatible. You can use X.509. You can
even talk to people who use something different. Because the complexity is out
of the client, you can talk to any service.
Mr. Benedict: How mature is
this in the products? Is there really something there that doesn’t care whose
PKI system I use?
Dr. Hallam-Baker: Only from
VeriSign’s point of view. We’ve been running an XKMS service since July, 2001.
The last call at W3C has ended, and the specification will go to a vote as soon
as I’m finished editing it. The standards group was attended by Microsoft,
Baltimore, Entrust, and I believe RSA. It is an industry-wide effort.
Mr. Benedict: So this
rationalizes the problem of different implementations of X509?
Dr. Hallam-Baker: It also
rationalizes the Federal Bridge Certification Authority [CA]. It’s not a hierarchical
PKI. When you try a hierarchy, you have a lot of complexity, so one of the
reasons why there’s a lot of commercial interest is that it’s a way we can do
the Federal Bridge CA. The thing is, when Windows XP has Federal Bridge CA
version 1 coding, but only talks to the Federal Bridge CA with single nexus.
Now when the U.S. does it with its allies and NATO, the Bridge inevitably gets
more complex. We don’t want to have to re-deploy XP as a way of upgrading; we
have to take it out of the desktop to make it manageable. We want to move the
complexity where we can manage it, so we put Web Services in place.
Mr. Steve Schmalz: One question
I have with the standard is, if you offload too much of the client
responsibility in validating the certificate, etc., you have a “chicken and
egg” thing, where you have to worry about finding an XKMS service you can
trust. Is that leveraging PKI, or…
Dr. Hallam-Baker: I’ll come to
that in a moment. There is one point on the locating side—getting a PKI path
with an XKMS service that is trustworthy. You pull down the certificate chain
and do a chain validation. It’s easier than chain discovery.
Slide 20 [XKMS PKI Interface]: We’ve got an
authorization decision. We’ve broken it down into two questions, then three.
The first is authentication; “Is Alice the real Alice?” The second is, “What do
we know about Alice?” The third is, “What do we do to get access to the file
anyway?”
Slide 21 [Example: Federal Bridge Certificate
Location & Validation]: What we want to do is to distribute the
problem across the cloud. At the moment, if it’s built into your services, if
you have a data center with 50 machines—each with its own authentication and
authorization system—you’re not going to upgrade, because you’d have to upgrade
every machine to understand that authorization system. The second thing is, an
attacker can take advantage of differences in authorization mechanisms. The
third problem is a “single sign-off” problem. Enterprises talk about “single
sign-on.” It’s really sign-off. “We’ve fired Mallet. He’s gone, and we want to
yank his ability to talk to every machine before his feet are on the pavement
outside.” One of our customers said they need thirty minutes. It’s not
instantaneous, because of the length of the termination interview!
Slide 22 [Distributed Access Control]: The first
piece is authentication: the user talks to an authentication service. You can
do any form of Web Service you want to. The application now only needs to know
a single mechanism for recognizing the fact that “Yes, Alice is Alice, and you
can trust that information”—so one mechanism is needed to support it. The
second part is that authorization decision: “Should Alice be able to look at
the General Ledger or not?” You send the question to the authorization server,
and it makes the decision at a global level. There are other advantages. The
problem here is, you have 20 machines that don’t talk to each other. Say
Aldrich Ames gets five queries from Server A, five from Server B, and five from
Server C. He can make many in a day. If the system doesn’t know it at a global
level, you might not know the extent of the problem. Looking at Madonna’s tax
records might be OK, but if it’s Madonna, Lionel Richie, and Stevie Wonder, you
know you have a problem.
Slide 23 [Distributed Access Control (continued)]: We have the
authentication, then authorization, then user attributes come through. “Is
Alice creditworthy?” The boxes in blue are SAML. The one in red can be either
XACML or XRML. The difference between them: XACML focuses on HIPAA problems,
and XRML focuses on digital rights management problems. The main reason to
standardize is if you want to move around. There’s not a desperate need to
standardize for within an enterprise, but there is a desperate need to
standardize the blue boxes, because the big problem with single sign-on is not
building the boxes, but rather connecting to your infrastructure. It used to be
Shim, then a big stack of Shims that talked to PeopleSoft, etc. We have Web
Services. They are integration, so standardize that. If you put out an
RFP, just put in a little line to say it has to support SAML to support single
sign-on. Pretty soon single sign-on will be possible and maintainable, because
you’re not going to have to rip off your system every time you buy a new
product.
Mr. Schmalz: I hear XRML
and SAML are competing, but as you know they might not really be. Is there a
history I’m missing?
Dr. Hallam-Baker: The history
between XRML and XACML can be read in the standards meetings. The other issue
is, some people say, “We don’t need SAML—we have Kerberos or some other
infrastructure that meets the need.” Yes, there’s an issue there, but not one
that’s a standards blocker. People play nice, except with XRML and XACML. The issue
is the patents. Microsoft is currently being litigated.
Slide 24 [Part IV Futures]: [Title Slide]
Slide 25 [WS-TrustAxiom]: It can’t be
turtles all the way down. Steve posed the question, “If the application is talking
to an XKMS server, how does it know it can trust it?” One way is X.509
certification. People say, “That’s not very good,” so the other answer is,
“Call another XKMS service.” The question is, how can you trust that service.
It can only recurse so far. You have to have a base case—a static mechanism, so
the application can talk to the XKMS server.
Slide 26 [WS-KeyAgreement]: Finally, the
other question on performance: the biggest problem with security is having to
sign or encrypt every time, so we use Kerberos—but that doesn’t have agreement,
it doesn’t go through firewalls, etc., so we need a public key to establish a
framework of trust. Then we can use symmetric cryptography. That’s what it’s
about—getting a bunch of experts to look at the protocol and check for bugs. By
the time you see it, it’ll probably be solid. We want to prove the security
before revealing it.
Mr. Marion Royal: Do you only
use symmetric key for encryption, not non-repudiation?
Dr. Hallam-Baker: Good
question. We use SSL to provide encryption and lightweight checking, and if it
checks, only then do we check the signature. This came up in standards
meetings—“Should we use symmetric or public key?” In most cases, symmetric is
OK. There’s no point in non-repudiation unless you archive that message,
however if you check the signature, you put an integrity check on top of it.
Mr. Ambur: The first
bullet on this slide caught my attention. [Editor’s note: The bullet says, “We
Can’t Sign Every Message.”] We have Lisa Weber here from NARA. Several years
ago I heard a presenter say he thought email would become the killer app for
digital signatures. My thought was,
“No, email is most approriately and best used for quick, informal messages, which
are by definition relatively low-quality records.” Why waste time and computing resources on relatively low-quality
records? What should be digitally signed are forms and other documents
containing business-quality information, and they should all be managed in
DoD-certified electronic records management systems through their full
lifecycles. We should not be using
email systems as quasi document/records management systems. Email systems are now being misused. Overcoming such misuse is a matter of
organizational maturity.
Dr. Hallam-Baker: Well, apart
from Spam.
Mr. Ambur: Are you
familiar with the NARA guidance with respect to PKI records?
Dr. Hallam-Baker: When did it
come out?
Ms. Lisa Weber: A couple
years ago.
Dr. Hallam-Baker: I believe I’m
familiar with it.
Mr. Ambur: NARA is
responsible for permanent records, so the keys required to access encrypted
records may need to be maintained and managed in perpetuity. By contrast, for security purposes, keys may
be routinely revoked. So there must be
a reliable system for recovering them.
Dr. Hallam-Baker: That’s the
main reason why XKMS has key recognition built in—because you may not have that
employee working there. You have personnel records, released 20-30 years after
the fact. You can’t ask for the public key at that point, and you probably
don’t want them around unencrypted in the meantime. The archival piece at the
moment—a few pieces are in place, but we don’t have a good one yet. SAML is
actually joining two different specifications. The trust assertion framework—the
idea was a signed object would have a unique identifier. That would be the atom
you’d put into a record management system.
So that concludes it.
Mr. Matthew McKennirey: Is there any
way for the relying party to know the integrity has not been compromised?
Dr. Hallam-Baker: You have to
know if the Web Services authenticates. “Was it an unsigned message because it
was a bad guy, or because it’s the policy of the service?” You have to know the
policy. In terms of integrity checking, the Web Services stack should look at
the authentication.
Mr. McKennirey: I can understand how Web Services can authenticate my
request to it, but how do we know the Web Service itself is functioning as
intended? What’s the integrity on the Web Service? How do we know it does the
same thing as yesterday?
Dr. Hallam-Baker: At the
moment, we have to trust it. The only way is with secure hardware. One of the
people on XKMS, for two years, has been designing Palladium. With Palladium, it
can inquire what you are running. This is the fingerprint. There are ways we
can do it in the future, but we can’t do it at the moment. If you want to do
supply chain integration, it’s a critical question. For me, it’s not about the
recording industry, which does only a few $ billion a year; the supply chain
industry is hundreds of billions. That’s where I think it’s really necessary.
End presentation.
Mr. Ambur: If there are
no more questions, the next presenter is Steve Schmalz with RSA.
Steve Schmalz
RSA Security
Secure Minds
Slide 2 [Agenda]: Phillip
showed you the whole car. I’m going to open the hood up and get some dirt on
our hands. I want to very quickly show you:
·
an XML SOAP message,
·
a SOAP message using an
XML digital signature,
·
SAML and SOAP,
·
a SOAP message carrying
a SAML assertion, and finally
·
a SOAP/SAML/XML digital
signature.
Slide 3 [XML Signature: Structure]: So here’s a
quick look at an XML digital signature. I’m sure you all know that the beauty
of XML digital signature is that it leverages the structure of an XML document;
what it is not, is a classical digital signature in the form of an XML
document. Instead, we have a manifest, which lists each protected resource
along with a message digest of that resource. This manifest, along with other
information such as which cryptographic algorithms to use, is what is actually
covered by the digital signature.
Slide 4 [WS-Security Core: <Security>
Element]: Now we’ve heard mention of the Web Services Security Core
standard, which has sort of firmed up recently. It describes how to use XML
digital signatures and Encryption within SOAP messages. The standard defines
the method by which Security headers (containing XML digital signatures,
Security Tokens and XML Encryption tags) can be added to SOAP messages.
Slide 5 [Signing Input Document]: Here’s an
example of a SOAP document: you have the envelope, with no header. You have the
body of the message—in this case, the price of a pool table and the account
number of the person purchasing it.
Slide 6 [WS-Security Example Signature (1 of 2)]: So here
everything is the same, except you have a security header where the XML digital
signature goes.
Slide 7 [WS-Security Example Signature (2 of 2)]: Here is the
digital signature. An important addition provided by the Web Services Security
Core is the ability to reference a security token. Notice that the digital
signature points to a Username token: in this case, it tells us that the
Username is Bob. This helps determine which X.509 certificate will verify the
digital signature or, if a symmetric key signature is being used, the location
of the associated password or key.
Slide 8 [Web Services Security vs. SAML]: So why mention
SAML in this context? Let me remind you that this stands for Security Assertion
Markup Language. Messages carrying these assertions are not by default secure.
Suggestions are to send them by SSL or apply a digital signature, and/or
encryption to the assertion within the message being sent.
Slide 9 [Attached SAML Assertion]: So let’s look
at a SAML assertion. It’s important to note that it can be inside the security
header. It can be a security token.
Slide 10 [Referencing a SAML Assertion]: You can
reference a SAML assertion because you can reference a security token. All I’m
showing you here is how a security token references back to an assertion.
Slide 11 [Signed SOAP/SAML]: Now let’s put
it all together. What’s going on is, within the security header you have a SAML
assertion. In this case you have an authentication statement and here you have
an attribute statement. Inside you have a subject confirmation: within it is
something called “ConfirmationMethod.” Notice it says “holder-of-key.” (Let us
assume that in this case the authentication process is public key based.) It
means that the process sending the SOAP message is going to prove it has access
to the private key associated with the public key certificate. If I’m reading
the standards correctly, one way to do this is to sign part of the SOAP document.
Slide 12 [Signed SOAP/SAML (continued)]: In this case,
the digital signature produced covers the message body. You’ll also notice
another digital signature inside the SAML assertion. That digital signature
covers parts of the SAML assertions. What parts should it cover? You can guess
it needs to cover this stuff—specifically this key value. So if we put it
together, it’s very nice. It allows you to transport SAML assertions in a way
that gives you a nice level of trust. If the assertion is my name and key, it
has proof that the process has access to my private key with that claim, in
turn, being protected by another digital signature.
There’s another way of
doing this. Rather than saying ‘holder-of-key,’ there’s another phrase, “sender
vouches,” where the sender promises access to the private key. Which is
preferable? Let me tell you a quick story: it’s my job to follow sales people
and explain the products we sell, so I get to hear a lot about technology.
Usually they’re just explaining what they need to do. I can’t tell you how many
times I’ve talked to a government customer who said the following. “I have to
have my application public key enabled and I’ve decided to focus on the
authentication process. All I need to do is ask for the X.509 certificate,
right? If I validate the public key certificate that proofs the user’s identity,
right?” Unfortunately, I have to disappoint them. Just because you send a public
key certificate doesn’t mean anything. It doesn’t prove I’m Steve Schmalz. After
all, it is a public key certificate; the assumption is that anyone can get
their hands on it. I must use my private key in some way combined with my X.509
certificate to truly prove my identity. I’m glad to see this important concept
expressed clearly in the standard.
So that’s a quick look
under the covers. A plug for my company is that we have a great new site for people
writing security code. You can look up the white papers. We’ll be happy to post
any relevant material you have as well. Oh, and just in case some of you here
do not know, 7-8 years ago, when VeriSign started, they came from RSA, so
there’s lots of history there.
Mr. McKennirey: How can you
trust the thing providing the SAML assertion? How do you know the thing making
the assertion is trustworthy? What level of assurance is there that whatever or
whoever is running it is something I can rely on?
Mr. Schmalz: Somehow you
use a digital signature.
Mr. McKennirey: When you’re
making a request of a SAML authority, who is the authority and why should we
trust it?
Mr. Schmalz: Why trust a
public key or X509?
Dr. Hallam-Baker: There are three containers in a SAML
assertion:
·
The first is a
statement.
·
The second is a set of
conditions, like “Check this URL,” or an online service, or another assertion.
·
The final section is advice.
You can put anything in there. It doesn’t affect the semantics, but it affects
the processing. You could attach a proof—say you have the authorization
statement, based on policy and attribute assertion. You can attach those three
statements. If you have a well-defined policy statement, you can put it into
that slot.
·
You ask how one knows
the axioms. You can’t know, but you can correlate over time. If someone
introduces a false statement, you can pick it up over time.
Mr. McKennirey: How can you run
a SAML assertion authority over time? Internal? External?
Dr. Hallam-Baker: Both.
Internal for your own use—for example, “Is Alice credit worthy?” But “I’ll
insure Alice’s credit” is a different one. If General Electric insures it, it’s
fairly credible.
Mr. McKennirey: Any time you
rely on a third party, whether it’s SAML, a certificate authority, or XKMS, the
issue is, “How do you rely on that authority?” It’s a policy issue. The
technology is fine, but if the SAML assertion is coming from the “First
National Bank of Boga Boga Land for DoD, I’ll have a different view.
Dr. Hallam-Baker: It comes down
to the policy applied, the level of risk, separation of duties, and that good
stuff from the MILSEC [military security] world. That’s how you make a system
secure. You design it so there’s no single point of failure.
Mr. Schmalz: I think we
are missing the key point about trusted third parties here; and that is that
you have to start with a point, or anchor, of trust. No, I would not trust the
First National Bank of Boga Boga, unless another bank I do trust told me to.
This is security in the real world.
Mr. Royal: Another is, “There
are some hardware things you can do.”
Mr. Schmalz: I look at
access control as being the key to security. For encryption in the modern world
of strong well-tested algorithms, it comes down to “Who or what has access to the key? How well is it being protected?”
When encryption is driven by a human being you can tie it to an authentication
process, such as a password, that can protect the key when it is not being used
– but what do you do when the encryption process needs to be automated? The
answer is physical access control, which is what hardware gives you. There is
even a government standard call FIPS 140 that covers this. (http://www.itl.nist.gov/fipspubs/).
Mr. Ambur: Are there any
other questions for Steve? Well, we’re good on time, so let’s take a break, and
come back at 10:35.
End presentation
Mr. Ambur: OK, let’s get
started again. There is a sign-in sheet
if you’d like your presence recorded for the minutes. For those who came in
late, if you’d like to introduce yourselves and tell us a bit about your
interest in XML, we’d be happy to hear from you.
[Introductions]
Mr. Roy Morgan: I’m Roy Morgan
from NIST [National Institute of Standards and Technology (http://www.nist.gov/)]. A note for all who are
coming to the XML Project Team—we’re having a meeting with the E-Forms Team
from [Department of] Commerce [http://www.commerce.gov/],
so please join us in a joint meeting for E-forms for EGov after this meeting.
Mr. Ambur: Next we’ll
hear from a couple hardware vendors.
Previously, we’ve heard primarily from folks with software and
data-related expertise. This is the first we’ll have heard from hardware
vendors. I’m very interested to hear
what Eugene and Mamoon have to tell us about the justifications and potentials
for XML processing in hardware components.
Eugene Kuznetsov, Data Power Technology
Mamoon Yunus, ForumSystems
Hardware Based XML Security Components
Mr. Yunus: I’m Mamoon Yunus and this is Eugene
Kuznetsov. We thought we’d give a very short presentation, and try to save a
lot of time at the end for questions and answers.
Slide 2 [Topics]: Our topics
are:
·
XML webServices Security
·
Enterprise Deployments
for XML Security
·
Hardware-Based XML
Security
·
Interoperability
·
XML Security and FEA
We’ll try to frame this
around how hardware fits within the Federal Enterprise Architecture [FEA]
framework.
Slide 3 [Need for XML Security]: Let me set
the stage a little on why we need XML security. SSL was developed by Netscape
in the early 90s to secure transport between
client browsers and a web server.
SSL has been mostly effective in securing such person-to-machine
communications, however, with the advent of [DP1]XML, Internet-based machine-to-machine has been
introduced. This XML machine-to-machine
communication is protocol-agnostic.
Now, you cannot ensure the protocols are secure, such as FTP. You have
an environment where XML documents would traverse multiple HTTP connections,
and multiple security domains. Getting protocol-independent granular privacy,
through XML encryption [http://www.w3.org/Encryption/2001],
and granular integrity, through XML Digital Signatures became very important.
So companies like DataPower and Forum Systems take care of the complexity of
XML security, as well as transport-level issues, so the problem is more
comprehensive transport and content security. In the FEA [http://feapmo.gov/], there’s a framework, a
Component Service Reference Model, and a Technical Reference Model. The
security is captured with it. So the FEA recognizes that it’s an issue of
transport and data-centric security.
Slide 4 [Technology and Specifications Landscape]: Quickly, most
of you are familiar with the landscape. This is kind of a map to show how it
falls within the Technical Reference Model (TRM). You have a foundation, and
XML, DTD/XML Schema, XPath/XSLT, and SOAP fall in with the different
specifications. The way the specifications are laid out is, they start out with
the high-level TRM, then service areas, then component frameworks. All these
are service specifications that fall within the standard. The other XML
security standards are digital signature [http://www.w3.org/Signature]and
encryption, though now in the FEA they’re subsumed by Web Services security [http://www.oasis-open.org/committees/wss/].
SAML [http://www.oasis-open.org/committees/security/],
we talked about earlier. SAML is in there. XKMS and XACML are not in there.
UDDI is addressed very well.
Slide 5 [Sampling of XML
Security Threats] [Mr. Kuznetsov]: Here we talk
about the security threats:
1. Snooping—XML is text, so anyone can see the material,
whether on the intranet or over the Internet. The reality is, you never rely on
security through obscuring, but old binary formats do make it harder to snoop
on traffic. Here, you’re talking about plain text. The things that make it
[SOAP/XML]easy make it easy to get the information.
2. Then there’s tampering. An example is in a
semi-trusted environment. When we talk about threats, we frequently talk about perimeter
security. You have an issue where it’s not completely inside or outside. Maybe
it’s a financial institution with multiple divisions. How do you enforce that?
It’s like what happens with large automakers; they cooperate on some projects,
but they’re fierce competitors. It’s like DataPower and ForumSystems sharing
PowerPoint slides – we want to make a joint presentation, but we don’t want to
share source code! We have a gray area within semi-trusted environments. It’s
not a binary, “on/off”, solution. Gartner [http://www4.gartner.com/Init] talks
about “dissolution of the perimeter.” That’s some of what we’re talking about.
3. Unauthorized action via a valid interface—there is
some valid function exposed, but a particular Web Services client shouldn’t be
allowed to access it. Really the problem of authorization--“Who is allowed to
do what?”
4. Breach of memory space—for the last four-five years, there
have been attacks against HTTP stacks. XML rides on top of that, but we’re
talking about a range of stacks now: XML, SOAP, digital signature, encryption,
WS-Security, SAML… There are a lot of things to get wrong. Unless you start out
with the goal of making security, there are lots of bugs you can have, lots of
variability, and lots of complexity, so it’s harder to secure.
5. Unintentionally exposed interface—a lot of application
servers make it easy to expose Web service automatically. Lots of time, you
expose data or fields in a record that shouldn’t be exposed. You take an
application, run through a wizard, it sets out WSDL, and suddenly you’re
talking SOAP. We need to police the security rather than the software
development.
6. XML Denial-of-Service (XDoS)—it’s either an attack at
the XML level, or asymmetry of XML processing. For example, you and I have an
algorithm: it takes me a second to compute it. It takes you 10 seconds to
decide not to validate it. It’s easy for me to overwhelm you. We heard about it
in PKI. XML is very similar. It’s easy to generate large volumes of XML. It’s
difficult to parse and validate. Its size is obscured, so if Web Services
expects a 10K file, it might get a 10 MB file instead. That would take a long
time. We’re talking about a tenfold
expansion. We’re talking about 200-300 MB to be consumed.
Mr. Schmalz: SOAP messages
have the ability (in headers) to mitigate against this. I’m betting your
hardware divides it to take advantage of multiple processing ability.
Mr. Kuznetsov: Sure, there
are some possibilities. Lets say the payload is much larger than expected:
unless you do some restrictions, you have a problem. I’ve been talking about
DoS attacks on Web Services for three years; people looked at me like I was
crazy. But one of the things we saw recently in the wild was a 2K XML file.
You’d try to open the file, and you’d lock up your computer, because it was a
recursive expansion attack. It’s a small file, but it’s expanding, and you
process it until your computer runs out of memory and shuts down the processor.
It’s a race. As new threats come out, people try to keep up with them.
Mr. Yunus: The SOAP
header stuff does help. You can still get issues in the body of the message,
but it’s still a good start.
Slide 6 [XML Security Deployment Ecosystem] [Mr. Kuznetsov]: Everyone is
going to support digital signature, or XML security, or SAML, so this is where
hardware devices sit with respect to the others. In green is the plain data
flow: There’s an application server—WebSphere, maybe Oracle. Some Web Services
enable the application; it could be a legacy application with a Web Services
toolkit. Now look at all the pieces of the control scenario, in blue: it could
be XKMS to a VeriSign PKI server. It could be outsourced to the PKI service
(VeriSign or a government entity). It could by a CA server. It could talk to an
access control policy server (say, IBM (probably LDAP today)). Maybe it’s
redirected. In the long run, we have XACML, XKMS; we have an access control
policy server—then a service registry of some kind. If I have an application
going outside my department, where should it find its service? It’s much like
DNS; only we have entries for Web Services, rather than websites.
Interestingly, we have VeriSign running one where we can find a service you
need.
Look at the output. You
drop an XS40 in. The functionality is very much the same. One reason we can do
this is because of the standards. We might have a gateway device spit out
information to a non-repudiation server. It all comes with a time stamp and
private key of the gateway. Legally, there are lots of rules about what you can
do. It’s becoming increasingly important. With computer crimes, you want an
audit trail. It’s a great place to do it, because you don’t have to audit
trail-enable applications, because you can look into the transaction, and you
can know what’s going on. You might have a network system security manager;
here it’s OpenView [http://www.openview.hp.com/].
It could be anything. It could be old, like SNMP, or something newer. Finally,
you might have a Web Services integration server, as a client, with the green
arrows. We talk about network infrastructure in the next slide. As you can see,
everything connects to Web Services hardware security devices. There are
policies, repositories, that control it all. You also have systems that collect
this information. You have devices as proxy and enforcement point.
Slide 7 [Deployment Modes] [Mr. Yunus]: Here we have deployment modes. We have the
XML hardware security device behind a load balancer. As traffic comes
through—it may be high speed digital signature for all SOAP messages, it may be
archiving, or inserting SAML assertions—all the classic security functions are
pushed out to the perimeter. There’s a real necessity for offloading these
expensive functions. Classic processors cannot keep up with XML processing and
application processing, so we need to offload it from regular servers. One
point from earlier is security problems within the company, so as information
flows within firewalls, these can be the gatekeepers between systems—ensuring
integrity and obfuscation provided by XML encryption—so these are both at the
perimeter and deep within the corporation. So encryption, SAML, and digital
signature…those kinds of things are done at the edge and within the
corporation, so from a deployment standpoint, it’s very flexible.
Mr. Ambur: It reminds me
of an issue regarding the Privacy Act.
In many cases, like with your Social Security Number, the problem isn’t
that other people know what it is. The
problem is what they can do with it without being easily detected. So having an audit trail is key to stopping
the misuse of Social Security Numbers and other sensitive information.
Slide 8 [XML Security Gateway Deployment]: Again, to put
it within the context of the FEA, this is a snapshot from the TRM specification
1.0. It shows the outside world, the internal environment, and the
“demilitarized zone” [DMZ]. I think these devices sit within the enterprise to
do the classic security. Within the security architecture provided by TRM, I
think this works as well. We need to have signatures at a granular level, so
only those with authorization to see it will see it on a need-to-know basis. So
why is information not shared across the network? We control it so only those
with the authority to know can see it. The other nice thing is that the TRM
provides service interfaces that are XML-based, making communication with XML
hardware devices straightforward. Deployment within the TRM framework is
non-intrusive; the devices are easy to drop into the architecture.
Slide 9 [Digital Signatures] [Mr. Kuznetsov]: So we’ve
covered digital signatures in detail, so let’s look at the next context. You
may have a partner that sends a SOAP message. It’s good to use SSL; it’s OK,
but not sufficient. It goes to a public DMZ, then it verifies the signature,
either in gateway mode or service mode, where the service verifies it, then passes
it through to the application server, which can use internal signature
verification. One of the issues is, it’s a single place for key storage,
signing policy, and verification in regard to a larger system. Imagine if you
have 50 PKI-enabled servers, with their own toolkits. They all have to be
updated, and deal with incoming traffic. It’s a huge management problem. If all
you do is have application servers call out to a single point, you don’t have
these issues. Hopefully it means it’s easier to deploy this technology than
otherwise. One thing you can do is sign all outgoing messages. It’s a different
approach to security than one that says, “Wait for standards to stabilize, and
get agreement on all the issues.” The one thing good about Web Services security
and XML security standards is, they’re componentized. You can use digital
signature without
SAML or anything else.
Look at all the specifications and names, and you can’t figure out anything,
what they all mean, but actually it’s a good thing. It means all the standards
are very well factored, rather than monolithic standards. It starts simple, but
it does all these other things as well.
Slide 10 [Sign All Outgoing Messages]: The whole
point of Web Services is to stay loosely coupled, and heterogeneous. If you
apply the same set of technology to digital signature and signing, you can do
the same thing there. Then you can go back and verify you’ve sent a signature
on your message. The recipient doesn’t have to be able to do it. You can go
back and make sure it’s not tampered with after the fact. Over time, it
encourages the recipients to build up their infrastructure. It’s an easy way to
improve security. You don’t have to have agreement. You say, “You’ll get
messages, and they’ll be signed. We recommend you verify them, but at least
store them.” The only reason not to do this is performance. With a large volume
of messages, you need some tool that can do it at a reasonable speed.
Slide 11 [XML Filtering] [Mr. Yunus]: Another use case is filtering of messages.
As Eugene mentioned earlier, even small messages can wreak havoc, so how can
you have perimeter checking that is legitimate, well formed, and valid? The
easy way is to check against the XSD or WSDL [http://www.w3.org/TR/WSDL] Make sure
there’s no buffer overrun, or that it’s overly taxing. So one of the things we
see in the market is message schema validation of the request and of the
response. Another is DSIG verification--to see that the signature is not
tampered with internally or externally. Another that we see is deployments
where a hardware security gateway is used as a translation between protocol
level and SAML assertion; so as it comes in and hits the gateway, there’s SSL
client-level authentication, and the SAML assertion is injected into the SOAP
message. So it acts as a clean gateway for SSL and SAML, but you want to verify
the authenticity of the individual and then insert your SAML assertion.
Mr. Ambur: It sounds
like it could be a partial solution for long-term record keeping, where an
agency can certify, when received, that the signature is valid, and not
necessarily maintain individual signature records indefinitely.
Mr. Yunus: There are a number
of single sign-on solutions at the back end, so it’s a well-developed area
right now.
Slide 12 [The Need for Hardware
Based XML Security]: Now for the crux of the presentation: why
hardware? What’s the advantage? There
are four issues:
·
Hardware XML security
reduces complexity.
·
Hardware XML provides
hardened security.
·
Hardware XML security
delivers superior performance.
·
Hardware XML security
encourages interoperability.
Slide 13 [Hardware XML Security Reduces Complexity]: We start off
with the central point of managing complexity. Instead of security policies
across multiple servers, and the cost of developing and maintaining them, the
way to reduce is to have a device taking care of the complexity of the policy,
for archiving in a central way, and to relieve the servers of the management.
Slide 14 [Hardware Provides Hardened Security]: On the
hardened security part, when we look at classic firewalls and software
solutions, we have to look at Operating System [OS] upgrades, patches, hardware
upgrades, et. From an interoperability perspective, if we do an upgrade, we’re
going to have a conflict with the OS. In a hardware solution, it’s all taken
care of from a single point of accountability. Also, when hardening the OS, you
have daemons people don’t shut off. You haven’t hardened your hardware. You may
have installed a firewall, but left a rogue process running that comes with the
OS install.
Mr. Ambur: Have you
looked at Security-Enhanced Linux?
Mr. Yunus: No.
Mr. Ambur: The National
Security Agency (NSA) developed SELinux because they argue that all of the
other operating systems are inherently and fatally flawed from a security
standpoint – because if you gain root priviledges, you have access to and can
change everything. That is unacceptable
from a records management perspective, particularly for highly sensitive
records. The reason NSA focused on
Linux is that it is open, so they can scrutinize it and make sure that any
security flaws are corrected – unlike other operating systems. I encourage you to look into SE Linux. NSA might be a good target for your
products.
Mr. Kuznetsov: If you have
complete control over hardware, software, and firmware, you have a better
opportunity than if you have a variety.
Mr. Schmalz: Does it do
FIPS 140 processing?
Mr. Yunus: It’s in the
process.
Mr. Kuznetsov: If you’re
doing key encryption, the worry is how easy it is to steal the private key from
the device.
Mr. Yunus: If you let the
application developers do the security, they might use weaker algorithms. If
it’s a hardware device, it’s FIPS 186-compliant anyway. It doesn’t have the
weakness of some of the other issues.
Then finally the biggest
issue we see is, separating security policy from the application. They’re two
separate roles. You don’t want application developers writing security codes.
Applications continue to evolve. It could introduce security issues. It’s
better to separate it to where security people can have better control over it.
Slide 15 XML Cryptography & Security Performance: Hopefully,
you’ve seen that performance is one of many reasons why you might want one of
these. Others have to do with security and reducing complexity. We all know
that cryptography is very expensive. An example is SSL. I’ll just offer that
there’s a lot of hardware acceleration today. It is enough of a problem in
these days of E-Commerce that people are accounting for it. In security, we see
multiple signed headers. You might have an asymmetric key, then symmetric
encryption. You might sign them, then one of the things you can do is sign
chunks of a document, saying, “This is the part I’ve read.” You could easily
get 10 or more public-key operations per message. Remember that there are
multiple messages per connection, so just in terms of the cryptography
workload, there are many operations. The good news is that the technology has
improved since the days of SSL, but this is just part of the equation. XML
processing is also very expensive (verbose, heavy).
Slide 16 [XML Hardware Encourages Interoperability]: Let’s talk
about how XML hardware encourages interoperability. It can be a way to ensure
that the standards efforts come to reality. They’re coupled to devices by an
Ethernet jack; the starting point is a phone or IP router (not a toolkit that
plugs into the application using not-very-secret APIs [Application Programming
Interfaces], and then lives in the application.
With this, it’s about a
separation of concerns and modularity. It’s just a way of applying it to an
area that’s often viewed as the area of application programmers.
Let’s talk about vendors
in the commercial space. The Network gear business model is based on
out-of-the-box interoperability. You order them, let’s say they’re all from
DataPower; then you haggle with prices, GSA schedules, etc. You buy your
product, and for the next project, you call another vendor. It’s very different
from a model of large software vendors providing a set of XML development
tools, where they hope to continue working with you and have you buy from them
again later. Interoperability is secondary to that. There are standards wars
we’re seeing precisely because of this—things in standards that are
inconvenient for one vendor versus another. The network vendors are unable to
achieve lock-in. Their customers can’t get locked in by using a proprietary
protocol. Instead, these vendors get more business by building a better
product, that’s easier to manage, and that doesn’t require special extensions
and APIs that force the customers to buy from you. They buy because you have
better products. Network hardware drives you toward more interoperable
solutions, because that is the business model. Buy online, ship to the data
center, and you’re up in minutes. You don’t even think to ask whether it’s
compatible TCP/IP from one vendor to another. That’s what we’re driving for
with Web Services: interoperability, ease of management, and security—not
building a platform and general issues of Web Services enablement or other
concerns.
Slide 17 [Overview of Hardware XML Security Market]: In general, a
lot of vendors in the XML security space (RSA, VeriSign) have an implementation
of XML signature, SAML, and so on. With a hardware specification, there are more
and more appliance devices. It can make selection difficult. If you’ve gone to
a recent conference, as far as you can see, it’s Web Services management. It’s
all different, but everybody’s doing it. What’s the correlation between Web
Services management and Web Services security? We say not much. Most are
relatively small companies. The hardware model is gaining a lot of
traction—maybe eight to ten companies. DataPower and Forum started out in
hardware, and maybe five with software. In the past months, many have moved
from software to a network appliance. People are struggling for easier
management and deployability, where they can just plug in. There’s still lots
of work to do. Now we have to evaluate it, not look at seven or eight vendors.
It’s so hard to do, but it’s going to mature.
Mr. Yunus: Look at
firewall companies. They eventually became hardware companies, so wherever you
have a security consideration, the network hardware solution is becoming the
one of choice.
Mr. Kuznetsov: Whenever it’s
new like this, it’s hard. Now when we’re encountering network hardware
management, people see what the need is. Standard support is the key to value
again—out of the box interoperable.
Slide 18 [Interoperability Promoted Through Standards
Bodies] [Mr. Yunus]:
Interoperability is always a hard issue. The good news is, it is
hardware—but standards bodies are working on ensuring that all vendors are
interoperable. WS-I has toolkits to ensure that vendors don’t transmit in a
specific way. SOAP Specifications Assertions and Test Collection is a
specification. SOAP 1.2 is a large document with 80 interoperability tests, and
a target to ensure that the SOAP message does the right thing, so the bottom
line is that a lot of thought has been given to interoperability, only it’s
firmer from a hardware standpoint because we tout that as the biggest cost of a
hardware solution.
Baseline standards have
been around a while. SOAP l.1 matured in 2000. SOAP 1.2 is different, but not
that great. Then there was XML DSIG in early 2002, SAML 1.0 in November of
2002, and WS-Security in April of 2002. These are fairly mature, and some are
in development. These building blocks are stable. There’s no reason to think
that interoperability is an issue. Simply from an ecosystem standpoint, all the
moving parts to support the subsystem are available. And the last point,
between heterogeneous environments, there are standard protocols to talk to.
Similar hardware devices—fairly standards-based—so from an interoperability
standpoint, it’s not a big issue moving forward with an XML hardware device.