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: We might as well get started. We have some folks here who attended the XML 2002 conference last week. Let’s take a few minutes to hear from them. Let’s start by introducing ourselves. If you were at the conference, perhaps you can give your observation of the main points you took from the conference.
[Participants introduced themselves.]
Ms. Lisa Weber: I attended two workshops. One was a basic XML overview; the second one was on Knowledge Management, by a German gentleman whose name I don’t remember. I got through about half of the slides. He talked about Topic Maps and RDF.
Mr. George Thomas: I also participated in XML 2002. I attended presentations that looked primarily at UBL.
Ms. Susan Turnbull: I was at the conference from Wednesday through Friday. I realized that I really know more about XML than I thought, but there’s a lot more to know. I was intrigued with the Voice XML session, because it’s part of the pilot that Brand led last year. I felt that the UBL presentation was significant. I was intrigued with one session on wireless XML where, once the standard is down, we can have an effective transmission rate to PDAs. I was interested in the session with Joe Carmel from the U.S. House of Representatives. He’s working on customizing the legislative process. The conference hosted/coincided with the first meeting of the OASIS EGov committee, and I was pleased to see that there were many countries participating.
Mr. Brand Niemann: I thought the whole week was a good opportunity to learn. I took a tutorial on native XML databases. I thought there was a good point by the instructor on the increasing role of XML in looking at Web Services as a long running process, where you have to store the metadata in databases, as well as the data. We had Kevin [Williams] there on XML collaboration tools. We [EPA] were the only non-vendor exhibit. The week culminated with the OASIS Technical Committee (TC) meeting on EGov. Many people who signed up expressed interest in this group, so I’ll share the email list.
Mr. Kevin Williams: My company, Blue Oxide, makes an XML collaborator software tool, which we displayed at the conference last week. I thought the conference was very good.
Ms. Susie Adams: I didn’t see Jean’s [Paoli’s] presentation. He gave the same presentation as he did here, with some more stuff on the demo. I heard a lot of talk about XDocs and XML capabilities of [MS] Word, as a revolutionary way to look at documents—having it be inherent to Office, with the pros and cons. The conference as a whole was great. I was trying to see as much as possible.
Mr. Ambur: Marion [Royal], my co-chair, is involved in UBL. When he returns, we’ll ask him about the conference. Our first presenter is Krishna Sankar. He’ll update us on SAML, which we first heard about when he spoke here a year ago. We’ll hear about what’s transpired over the past year.
Mr.
Krishna Sankar
Mr. Sankar: Please ask any questions you have at any time. I really see this as more of a discussion than a presentation. First, I’d like to give you some context of what SAML does, and some of the standards as they relate to XML. Then we’ll drill into SAML, and then there are some scenarios I’d like to point out.
Slide 3 [Views]: We have two views: W3C has one set (Infrastructure), and OASIS has the application-level standards. It almost looks as if the basics arise from W3C and the next layer up arises from OASIS. There are many more standards now. We need a diagram to make it all make sense.
Slide 4 [Technology Stack]: Here I’d like to make a couple points. We have a transport layer, message layer, business process layer, inter-process collaboration layer, multi-organization capability layer, and a discovery layer. The point is, security works at multiple levels. It works differently at different levels, which is why you need standards. We need to consider the notion of privacy as well.
Slide 5 [WS-XXX Processing Model]: Another important aspect to consider is that putting a message on the wire is not enough. There are things like Secure Conversation, Federation, and Authorization. I took this from the IBM-Microsoft Web Services security roadmap. We have to look at this and see that there’s a bigger picture before we get comprehensive security that we can distribute across systems.
Slide 6 [Technical Excellence Awards]: Just a note that Web Services and SAML got an award from PC magazine at the COMDEX. There are two things to that—first, the award is an honor. Second, PC Magazine has generally given awards for graphics cards, PCs, etc. (the hardware). Now it’s the protocols. They realize it’s not just the hardware, but how systems talk to each other. That’s a sign of the times. It makes it worthwhile to see that people recognize our work in the standards area.
Mr. Niemann: Were there any others in that category?
Mr. Sankar: Yes. Jabber [Real-time communication platform] was one, and the other was the serial bus. Jabber has more social impact, but they still chose us to get an award, so it was very nice.
Mr. Ambur: It’s encouraging that they’d recognize excellence in something that others might not care too much about.
Mr. Sankar: It’s also an honor to the folks who’ve been working hard on it.
Slide 7 [Communication Layers Conceptual Graphic]: Before I begin, I want to show you some of the things I’m working on. If you look at the layers, there are three layers—Transport, Message, and Service. Depending on where we want to put intelligence or add things, we need to decide which is the appropriate layer.
Slide 8 [Communication Layers Conceptual Graphic (build)]: Security is better at the Message than the Service layer. That way, all the applications can make use of that addition. The first blue box is the “Definition, Description, Discovery” process. Once SOAP Version 1.2 comes, we can separate the message process from the application process. At some point, it’s good to look at the third block—grid computing—which could be used to make the service layer.
Mr. Ambur: Krishna had suggested that he give a presentation on grid computing. I’m open to that, but I don’t want to do it before we have the building blocks in place. For example, NARA is considering its role in managing electronic records. It may not make sense for them to ingest terabytes of data from NASA but, one way or the other, services have to be there to manage those records and we have to make sure the necessary services are available on the network.
Mr. Sankar: We are actually looking at the grid computing concept right now. I don’t know which direction we’ll go in at this point.
Mr. Ambur: I’d be willing to hear about it if there is sufficient interest and the focus is clear.
Mr. Sankar: Platform security—we need to have multiple layers of security. We might have an authentication before the DMZ. We might also have to pass it to the back end, so it knows whether the authenticated person is the same as the one who is sending the data. So, when we do security, we need to address security across multiple layers.
Mr. Ambur: The need for security at the back end is commonly overlooked. Most of the focus is on protecting the transmission over the wires but the bulk of the risk occurs within the perimeters of the firewalls, where the records are stored, at either end of the transmission. A good example of the problem was recently reported in the press, with respect to off-track betting on horse races. Bets can be placed through a telephone keypad but the original records of the keypunches are not kept. Instead, the data is simply entered into a database. Since there is a delay between the end of each race and the point the results are entered and bets are paid off, a couple guys would simply call their buddy who had administrator rights to the database and he changed their bets to make them winners. Database systems are routinely designed that way. The point is, there is no such thing as information security unless the records are secured from inappropriate access and alteration, including by system administrators.
Mr. Sankar: I’m looking at labeled data security. Some military applications that I worked with earlier now make sense! If it’s an IP address, there are configurations involved, so there’s a need to label. I also am working in European Union security, so I look at privacy and confidentiality. I want to make sure that’s not compromised. There’s also a question of aggregation. People want to see how many occurrences of something are happening. We shouldn’t just get individual data; we should get the total data. The other question is one of queries. You can’t do them in a way to get the data. You can start from aggregation to a point where you actually can find information about a person. We need to look at all of those. We do need these multiple layers.
Mr. Ajay Ghandi: We had the same problem. I worked on a DoD project where there was aggregation, so we had to feather it. We had to remove the aggregation. We used Oracle security, and ran into that whole scenario.
Mr. Sankar: This is the backdrop in which we discuss SAML.
Slide 9 [Context]: I was here last December 18. Owen introduced me to the Federal Government convention in Las Vegas. I was preparing…
Mr. Ambur: The convention Krishna refers to is the Homeland Security Convention, held in conjunction with the big Consumer Electronics show that takes place each year. The convention was quickly organized in response to the events of 9/11. I participated in the program committee and we were glad to get Krishna.
Mr. Sankar: I have a briefcase with a number lock. Unknown to me, before I went to Las Vegas, my son had changed the combination of the lock. I got to the airport and didn’t know it. It’s a good thing no one asked me to open the bag. I would have been in deep trouble. Here I was talking at about Homeland Security, and I was going to have to ask Owen to bail me out of this. I soon realized what was wrong, so I started trying the combinations. Then suddenly I realized I knew where the bag had been and who did it (my son had been playing with it before I left), so by knowing the context, I could make assumptions about the situation, and the briefcase opened on the 9th combination I tried. I was very surprised, but the point is, in knowing the context, you can do a lot of things in the security world. You can use context to break a system, by knowing its vulnerabilities. On the other side, you can use context to make a system more secure. You see a message and say, “It never should have come here.” So there’s a problem somewhere. Or, look at it and say, “I’m not going to allow this person access.” That’s what SAML does. In some sense, SAML allows us to add context to XML messages. I thought that was an apt example.
Mr. Ambur: Would you agree that another word for context is metadata?
Mr. Sankar: Yes.
Slide 10 [What is SAML?]: By the way, the specification is 1.0, and it’s been ratified by
OASIS. It’s a set of vocabularies for:
·
Authentication
Assertion
·
Attribute
Assertion
·
AuthZ
Decision Assertion
·
Session
Assertion (Future)
·
Credential
Assertion (Future)
·
Standardizing
data traveling on the wire
Even if we standardize, if it’s vertical, someone else might not understand it. That’s why you need horizontal standards across systems.
Slide 11 [What is SAML, continued]: It’s also a standard for understanding assertions and how to respond.
Slide 12 [SAML Is…]: SAML is a standard way of exchanging security and related data across heterogeneous, distributed systems crossing domain (geographical, namespace, temporal, spatial, organizational…) boundaries. The advantage is, once you have SAML or any other security over the wire, dissimilar systems can talk with each other.
Slide 13 [Policies and Models]: When you look at the security aspects of a system, you have some entity (or principal), which has a credential. Then there’s a credential collector of some sort. It could be biometric, it could be a pop-up window, etc. Then comes the credential assertion that goes to an Authentication Authority. Someone says, “The credential is fine.” Is it the right one? You have to look at the policies and models on what’s allowable. It also looks to authenticate the entity and send an assertion, saying “It’s authenticated using this mechanism.” So, whoever trusts that Authentication Authority trusts that assertion.
There’s also a Session Authority which has the session assertion, so two systems that want to share data can do so. Things like AOL [America Online] Passport and internal security systems can act as Authentication Authorities. The Attribute Authority lets you know the role of a person. It says, “Yes this person belongs to this organization.” It could be many things. It could be things like credit cards. If you look at a credit card transaction, some Attribute Authority says, “You can borrow $5,000 dollars.” Or it could be a time server—“Do we allow this?” That’s the policy decision aspect, and then there’s the policy enforcement point. So this model helps to understand the assertions with respect to the authorities, policies, models, and how things work.
Mr. Ambur: There’s an E-authentication project underway as part of the federal government’s Electronic Government initiative. At this point, it’s just a validation service for user authentication. It doesn’t address user attributes, roles, or authorization policies. However, when GSA requested comments from the vendor community, half of the respondents said they don’t understand how authentication can be separated from authorization.
Mr. Sankar: There’s a whole line of debate that authentication is not different from authorization, that they’re tied together. They are tied together from one point of view, from but not from another.
So as long as we trust a particular entity, and as long as the assertion comes across the wire through a secured channel, then we can trust the authentication assertion.
Slide 14 [SAML Assertions]: SAML assertions are declarations of fact, according to someone. There are statements about subjects (authentication, attribute, or authorization decision). You can extend it to make your own assertions. That’s where the value comes in, because you should be able to extend it.
Slide 15 [All Statements in an Assertion Share Common
Information]: These are the common elements in an
assertion: Issuer ID and timestamp, Assertion ID, Subject, Conditions, and
Additional advice.
Slide 16 [Assertion Structure]: This how an
assertion looks [tree diagram]. You can say, “It’s not valid before or after,
but only for this usage.”
Slide 17 [What it Means]: The three assertions here are the authentication, attribute, and authorization decision. The attribute assertion, for example, “asserts that subject S is associated with attributes A1, A2, A3 … with values “V1”, “V2”, “V3”…” This assertion is delivered in response to the interrogation, “Please provide information on the listed attributes (A1,A2,A3,…) for this subject.”
The attribute assertion can be open-ended. The authorization decision asse5rtion says, “OK, I know about the domain. This is the authentication asset; this is the subject; the subject wants to do this.” It can send back a “yes” or “no.”
Slide 18 [JSR 155 – Web Services Security Assertions]: I am the lead for this Java API, so we are working on it. If you have multiple implementations, they would be isolated from the APIs.
Slide 19 [Scenario]: I had one scenario from the last time I spoke here. It’s still valid, so we can discuss it this time.
Slide 20 [Widely Distributed AuthC & AuthZ]: We want to enforce policies, but that should be independent from
management: otherwise, we have to do both—and if the policies come from
different places, management should reflect that. It needs some tie between
them, but they should be loosely coupled, not tightly coupled. You can’t scale
traditional access control lists, and having multiple management levels just
makes it too restrictive.
Slide 21 [Security Overlap]: This is an example from the Lawrence Livermore National Laboratories. You have an X-Ray machine. It says, “Exclude bad countries, and include LBNL staff. From the equipment perspective, users must have X-Ray training—so there are two domains with different policies. Whoever is going to access the equipment has to pass protocols. The R&D group also want part of it, so you have to pass their authentication as well—so you have to be at the intersection of these three to use the laboratory’s X-Ray machine.
Slide 22 [Access Control Intersections]: There are conditions to be met. How does it work? Look at the policy of “bad countries,” and you should have a list of the bad countries. Then LBNL membership; there should be a chart of members somewhere. So these things can be expressed in terms of access control markup language. XACML is one. Even digital rights management might apply here. It can come from different sources. On the right side, when someone wants access, you can use SAML assertions. You can combine all the assertions and compare against the access control list, and allow access. Then you know the person has satisfied all access assertions. It goes back to collaborating across multiple independent and geographically dispersed system stakeholders. It’s a good example of using SAML and these markup languages.
Mr. Marion Royal: Are you saying SAML isn’t enforcing or defining rules in a grouping of trusts, but provides a standard way of…
Mr. Sankar: Expressing them.
Mr. Royal: Is it “yes or no?”
Mr. Sankar: Typically it’s “yes or no,” but it could be attributes. There can be a bundle of multiple SAML assertions. You can pass in a variety of ways. You can even present your passport.
Mr. Royal: You might have information on a Smart Card?
Mr. Sankar: You might have it on a Smart Card.
Mr. Williams: I think Marion is edging around something I have a question on. In order for SAML on the right side of the diagram to function, all different authentication steps need to understand that that’s the same person for each step?
Mr. Sankar: Yes.
Mr. Williams: Is there a mechanism to make SAML understand it?
Mr. Sankar: That goes to the next topic of identity management, because there are multiple things. When you’re a student, you might have a student ID, but when you use a passport, you have another form. That gets to aggregation. Identity management is another dimension to this one.
Ms. Glenda Hayes: This appears to complement work in the intelligence community. They’ve developed a security schema that producers would include in an intelligence document. So you could mark up sections as secret or releasable to certain countries—that would be the XACML?
Mr. Sankar: No. That would be the SAML. XACML says who can access it. SAML would, if you look at the document, it has an attribute assertion with the type. It should be signed from the proper authority.
Ms. Hayes: It sounds as if SAML is overlapping the security schema they’ve been producing.
Mr. Sankar: That’s possible. If we use a standard way of doing these things, it’s easier to use commercial tools, and it can be widely used.
Ms. Hayes: On the other side, the intelligence community has an authority board for assessing acceptable terms and conditions to be required. It’s been coordinated for about two years now.
Mr. Sankar: Even if it uses a standard schema, it doesn’t make it all work.
I just have a few more slides.
Slide 23 [Hot From the Press]: Here are some other things that are happening. We need to express the quality of protection, privacy, and retention—further disclosure. We’re still working on a technical committee on this one.
Slide 24 [Web-Services Security Quality of Protection]: XNS needs to have a good identity management solution. We should hear from multiple folks on that, and start with some prototypes on that. We talked about that last year.
Mr. Thomas: Krishna, you started mentioning the Web Services policy, trust, and security. Do you have any take on the direction for other complementary specifications like WS Secure Conversation and WS Federation, and what it means to the SAML landscape? For example, given the landscape of the specification expressed as a business process, it could simplify the association. There seems to be a question between the two approaches.
Mr. Sankar: I’m also part of the OASIS Technical Advisory Board. I like to push for this cohesive architecture. Now there are standards coming up on different timelines, so we don’t see cohesion between them. My opinion is that it’s not going to happen for another year. The first thing is that other specifications will come up in the future. After about a year or so, we’ll realize we have them all. Then let us tie them together. OASIS has a security JC (Joint committee). It’s the one that would address it. For now, we should keep it like jelly, but after about a year, these things will come together, and we’ll see the advantages of these things.
Mr. Roy Morgan: Can you tell us about implementations of any of this?
Mr. Sankar: I know SAML is available from almost all the security agencies. It doesn’t become a standard until there are three independent implementations. XACML is also on the list to become a standard, so there are some implementations. Tying them together is the problem. The XMLP/SOAP layer [from earlier slide] needs to be built. If you have a tool that understands SAML, then when an E-authentication system sends out SAML, they can understand it
Mr. Ambur: GSA’s contractor has E-authentication working in the lab now. They’re committed to have an operational version by the end of September 2003.
Mr. Sankar: So this is a timeline we can look at for getting the domains aligned.
Mr. Ambur: That leads into the question I have, which is what this group might do to add value to what has happened and is happening with XML security standards.
Mr. Sankar: I think the answer to that and an earlier question is that this group can lead the architecture effort—define the underlying layers of the substrates—try to do some frameworks and prototypes.
Mr. Ambur: What you suggest is in line with the thrust of the crosscutting Federal Enterprise Architecture initiative under the eGov Strategy. The components and how they fit together need to be specified.
Mr. Dyung Le: I’m wondering how well your infrastructure supports the notion of delegation—something lightweight, as opposed to heavy-handed policy change. If I want to delegate, then turn off the authority immediately, how well does it do that?
Mr. Sankar: It’s something I’m working on. We have lots of opportunities for delegation on our projects. We haven’t had any problem on that line. The access control role layer under the definition/description/discussion area makes it easy to do.
We have a primary and secondary engineer—dedicated people who can do these network things. Those roles can change. The responsibility can be handed off to another person. One can delegate the responsibility to the primary and vice versa, so we can handle that challenge, but it’s a good point. Then there’s the question of doing the double thing, where an approval authority also can do things. We shouldn’t have that.
Mr. Ambur: Karen Evans, the Vice Chair of the CIO Council, has issued a statement of her vision for the CIO Council. We’ll link to it from the “What’s New” section of XML.gov when it’s available. It highlights the potential and importance of XML. [Editor’s Note: Ms. Evans’ statement is available at http://xml.gov/documents/completed/evansCIOCvision.pdf]
End Presentation
Mr.
Marc Le Maitre
OneName
Corporation
The
Identity Web: An Overview of XNS and the OASIS XRI TC
Mr. Le Maitre: Good morning. I really wear two hats, as regards XML. My capacity today is as a member of XNS.org.
Slide 1 [Goals of This Presentation]: It’s on the [OneName] website—the goal is to introduce you to a new idea called the Identity Web, and the motivating factors, and compare it with the World Wide Web (WWW), and introduce you to a beast called XNS, and provide an update on where XNS is going in standards—specifically the XRI TC in OASIS. I gave this presentation last week at XML 2002.
The next slide focuses on what XML means to the WWW.
Slide 2 [1992: What if…]: So I focused on “1992: What if…?” What was the problem then? Rendering digital documents in a common format and addressing and linking them using a common syntax. So, since there’s little invention in this world, some of the lessons from the WWW would be pertinent with the Identity Web. The next slide talks about how content evolved on the WWW, and how we can apply it when building an Identity Web.
Slide 3 [Evolution of Content on the WWW]: So I tried to build slides showing that it went from hierarchical file servers to publishing on Web servers in common markup language. It’s interesting to note that content still remains in control of the enterprise that’s publishing it—under their domain control. This was rapidly adopted because it was simple to use. It created a way to cross silos. What the WWW created was the linking across silos, a horizontal slice, a logical domain that became the WWW. These HTML links are the interesting things that allow us to create context between the content in different domains.
Tim Bray said that the Representation State Transfer Model of the Web is deliberately simplistic, but if they designed it again they would add certain additional features. One would be about the control of HTML linking. For example, there’s currently a big debate about how to control deep linking. I have content on my site that I don’t want people linking to unless they come through my portal (the front door.) How do I control this linking?
So these HTML Web links don’t provide adequate controlls to the people who own the content being linking to. The controls currently deployed aren’t part of the Web-linking process. They’re external. I put an access control list, (who can access content on my site), in a directory. Those directories don’t cross boundaries. The cross-domain sharing of directory information is different to the cross-domain sharing of content. We’re constrained by the directories that hold the access information. I put up a directory server, and put in your name and your access control permissions.
Slide 4 [Enterprise Directory Services Issues]: The whole thing becomes a directory consolidation problem. My description is necessarily a simplistic approach to a complex problem, but there are a couple of ways to consolidate directories. One is by affiliation, where I map the root node in mine to the root node in yours. The problem is, this does not scale well. If you try it on a global scale, forget it. Directory affiliation creates the “n-wise problem” because the number of maps required increases by a factor of n where n is the number of directory nodes to be affiliated. Maybe it’s not the best way to share identities across enterprises (sic).
Slide 5 [Meta-Directory Service Issues]: The second way is a meta-directory. This problem has been discussed and highlighted as part of the XML registry/repository work undertaken by this group and Booz Allen Hamilton. The problem is, all you do is increase the size of the domain to accommodate the other servers. Who’s going to manage your meta-directory? When you cross enterprise boundaries, meta-directories aren’t the solution because all of the directory owners have to lose some control of their data to the party who they may (or may not) trust to run the meta-directory.
Slide 6 [2002: What if…]: The solution to today’s data sharing problem is essentially the same solution to the original Web problem. The 2002 “What if” is the same as the 1992 “What if,” because it’s essentially a Web question. If I could render data in a common format, exchange it using a common protocol, and address and link using a common syntax, I’d be doing things the same as 10 years ago. If we are now linking data related to an identity instead of simple content, what would be the result? My assertion is, it would be an Identity Web.
Slide 7 [The Leap to a Web Architecture for Identity]: So we take a look at the architecture of an Identity Web and its challenges. Instead of Web file servers, we have directory servers (not just directory servers but databases, registries, and identity repositories). The first thing we notice is the problem of control. No enterprise is going to release control of identity information. The answer is to learn from the Web and publish identity data under the strict control and ownership of the existing domain. Identity Webs don’t publish to Web servers, but to Identity servers, which are similar beasts. Identity servers don’t publish in HTML, but in XML. Although this approach is intuitive to those who embraced the Web for content publication and linking, the challenge is persuading people that the model will work again, and to agree that this is the right mechanism to share identity information. The key is, we have to learn the lessons from the WWW—but this time think smarter about the markup and the linking. I’d like to talk about two things, the Identity tree for publishing the XML-marked-up data and the linking between the XML-marked-up data.
Slide 8 [The Web Identity Tree]: First of all, the publication of the XML data should be flat, not hierarchical. Relationships should be created by using linking—just like the horizontal Web. It should push control for distribution and management of identity-related data down to the entity that owns it. Everyone who publishes is responsible for what they publish and retains control of what they publish.
Slide 9 [Document Linking Versus Identity Linking]: The second part: linking in the Identity Web compared to the WWW. Both use URIs that point to another resource. However, linking in the Identity Web can get smarter than the linking used on the WWW. Instead of publishing in HTML, use XML. Define the links in XML as XML objects. Make the objects used to define the relationship in the links reusable. For example, the XML objects used to define relationships between identities are much like transaction receipts in a credit card system; you walk out of a store with an object that documents your relationship. They’re objects that can be referred to later on, that are distributed to either end of the relationship. We call them contract objects. They completely define the relationships to both ends of the links.
Slide 10 [Federating Identity Servers]: This shows how the links work. They define a relationship between two identities. These contracts can specify how we have a relationship. They can also act as links between aspects of my own identity. We can use contract objects that create a linkage between physical components of an identity that can create a single logical identity that is federated across a number of domains.
We can look at them as being components of a single identity—distributed, federated, and linked together again. The whole notion of a federated Identity Web is that existing HTML clients, browsers, and XML SOAP clients will also have to access it. From an implementation point of view, the Identity Web is rendered through existing Web servers and is not another layer. It is an extension of an existing layer.
Slide 11 [Identity Linking Close Up]: The linking is the key. Identities are hosted. It doesn’t have to be a big iron server (our company has put identities on smart cards), but they’re hosted in some shape. They are federated, so your identity doesn’t just exist on a smart card. Part of it does—maybe some critical parts—and some exist elsewhere.
For the host, you have identity documents, and within them you have attributes—but there are other attributes stored inside an identity document. One is a link object (an XML object that describes the relationship between my object and yours). It’s reusable.
Mr. Ambur: Does it use XLink?
Mr. Le Maitre: It absolutely can. We’re now rapidly going through all the XML standards in OASIS to make sure, with Krishna, that we don’t reinvent things.
The next thing is that a link describes a relationship between two identities or elements of identities, but a link itself contains elements that describe its context. Every time we describe a specific set of permissions, we create a contract for that. I can update it, archive it, create a new one, everything I can do now with a contract. The main thing it holds is the permissions.
Slide 12 [Contract Structure]: There are some human-readable portions of this: General Terms, Purpose, Policy references, etc., but the one thing it must include is a reference to attributes—what they are, who I shared them with, and what were the permissions I gave them? I’ll touch on that later. This contract can be digitally signed.
Slide 13 [Permission Objects]: There are two types of permissions that can be included in a contact: Privacy /Usage, and Access & Synch. Access & Synch is basically object linking, using a communications object to define the “Get,” “Set,” “Post,” and “Delete” functions in the HTTP REST model. It says, for example, ”Whenever my calendar changes, push the result out to the end of the link using this information”, etc. These access control permissions are written in XML.
The other type of permission is Privacy/Usage. It’s a complex topic because Privacy and Usage legislation differs so much throughout the world. What you can say generally, though, is that Privacy and Usage Permission types include elements such as Disclosure, Contact, Retention Terms, Purpose (a human-readable description), and Parties (for disclosure). The way we’ve designed it is as a container where existing or emerging “rights” markup language can be used. It’s not competing with P3P, but it is a way by which P3P policies can be signed and turned into contracts. Using an element to describe Parties for disclosure means you can daisy chain (or nest) these elements. If I had had this kind of control, I would have liked to have prevented my financial information from being shared when I moved to the U.S.
Slide 14 [The Negotiation Process]: Most negotiation is done by lawyers in a boardroom, yes, but in a simple negotiation, one side usually wins. In XNS, it’s “Here’s a form. Sign it.” As the negotiation process matures, you get to counter offer. “I have my terms; they don’t match with yours.” How do you handle it? Using schema and form definitions, sent to the requesting party from the publisher of the data. It goes on until there’s a dispute that can’t be resolved, or an acceptable agreement arises. We’re looking at another thing that has a similar process in it. There’s some overlap here. We want to see how much we can contrast to UBL and ebXML..
Slide 15 [The Synchronization Process]: The final thing is: once you agree on a set of contract terms, then the relationship starts. In the Identity Web, the relationship can be a one shot thing or it can be a persistent relationship with a Web of links under permission-based contracts. We’d like to be able to synchronize as part of our relationships, so we’re not grabbing documents that don’t change all at once. We’d like to do versioning to make sure we get the most recent data, which the Web doesn’t do well.
Slides 16, 17 [Skipped]
Slide 18 [XNS Design Requirements]: Some of this is 10 years old (not XNS—but the linking concepts are). The idea was to create logical persistent addressing. You know me as Marc. At another company, I’d still be Marc. We want it to be domain- and application-independent—a logical scheme for sharing and versioning. A stateless Web, not having a state, is another thing that Tim Bray recommended. Maybe we would do it differently in the Identity Web; have a state to recognize the latest version of a schema etc. Security and privacy controls are lacking from the Web as we know it today. We would use this persistence of exchanging and linking of synchronized data to make the Web a two-way street.
Slide 19 [XNS Consists of:]: So XNS is two elements: one is XRI, a syntax for addressing, and in some ways, versioning and, as it stands today, 14 WSDL services. Here’s the only prediction I’ll make: I think we’ll shortly have a debate between the REST [REpresentational State Transfer] camp and the SOAP camp—that is the Web purists who like a limited selection of verbs and many nouns, and those that believe the Web is a transport protocol. The REST advocates preach that WSDL is “bloatware.” They believe that everything can be decomposed into a limited set of primitives. I predict we’ll conclude that adding some more bits to the HTTP/REST model, and “dumbing-down” the panacea of the current view of Web Services is how we’ll end up. So we said, “What we’re trying to solve with the Identity Web is applicable to Web Services.” Then we recognize that if we can’t retrofit to the Web, we’ll end up with so many types of Web Services and a lack of interoperability, that we have to figure out how XNS addresses the REST architectural model. So the thinking is, how do you take 14 WSDL services and dumb them down? The vast majority of the REST crew believes it’s the way to go.
Mr. Ambur: That debate parallels what needs to take place in FEA and the Service Component Reference Model. My own bias is that simple is better than complex, at least as a place to start.
Mr. Le Maitre: That brings to mind Winston Churchill’s famous quote, “Sorry I don’t have enough time to make it that simple.” An analogy that I’ve read in the paper, and that I’ll post on the XML.gov site, compares the Web Services model to SGML and the REST model to XML. Sure, you can use anything in the container, as long as you tell everyone else what you’re putting in the container. That’s fine, but XML says, “Why?” Let’s constrain it a little bit and make it easier for everyone to agree on what’s in the container. I’m on the XRI TC because they’re not parallel tracks. The model to address and share content is inextricably linked to the markup and protocol set.
Ms. Hayes: I think that’s a debate that is already engaged. Doesn’t the current WSDL draft make reference to three bindings—the REST approach as well as the others? Each has its own utility, but they need to be evaluated for the nature of the interaction that’s required.
Mr. Le Maitre: Yes—what are the arguments? You’ve gotten to the nature of the discussion. It takes more than individual silos to figure that out. It takes the community at large. I’m not sure it’s hit its peak. I agree that some communities have recognized it.
Ms. Hayes: The discussion seems to have peaked in the summer, then tapered off.
Mr. Le Maitre: OK.
Mr. Ambur: Like HTML versus XML versus SGML, it’s not an “either/or” proposition.
Slide 20 [XNS Public Trust Organization (XNSORG)]: )]: I listened to Mark Crawford’s presentation
on UBL last week, in which he made several targeted references to “open” and
“royalty-free” products. I’ll refer to that as well, because when we first
presented XNS a year ago, that was his question. That’s been a challenge to us.
It’s difficult to persuade the “Powers that be” in your company to release
protocols in a royalty-free manner to the public domain, but it happened. On
July 10 [2002] we published the XNS specification in XNS.org. Some of the names
of the participants in XNS.org will be familiar to you. [Mr. Le Maitre listed
several companies.]
Slide 21 [XNS Specifications Title Slide]: [Skipped]
Slide 22 [XNS 1.0: A Two-Part Specification]: One of the main responsibilities of XNS.org was not to manage the technical specifications, but to pass them to a body in the right position at the right time. The XNS specification has now become a two-track process. Track one is XRI. This first part was submitted to OASIS in December to form the XRI TC. I encourage any of you considering naming and addressing syntax for XML objects to get involved with the XRI TC. We aim to combine the benefits of URNs, (of which the largest scheme is HANDLE) and the ubiquity of URI’s. We don’t intend to replace either, but rather to leverage both.
XRIs seek to take the benefits of URNs (that haven’t been universally adopted), and work them into a URI syntax, so that you simultaneously get human- and computer-readable identifiers. These can become memorable. My last look at the URLs served by many portals shows that they’re anything other than memorable.
Slide 23 [XRIs Extend the Benefits of URIs and URNs]: We recommend that some subset of identities has to be human-friendly. Some addresses have to be persistent, because resources exist beyond the life of a particular network representation. I move around, but remain the same person. These need to be privacy-protected. Having a single global unique identifier is not the way we all want to go. We want obfuscation in some cases. You can create an identity that spans namespaces, but represents itself logically, maybe in a different namespace using cross-referencing.
Versioning and cross-referenceability—We think it is essential to get schema versions within the URI. The idea of something being cross-referenceable is something that I did a lot of work on with Liberty Alliance. We were immersed in that debate for a long time. The ability to have a conversation such as “the object that I know as X is known by you as Y” is something that is missing from the Web today. One of the things we’ve done is submit the XRI scheme to Liberty as well. We don’t need too many addressing schemas out there.
Slide 24 [XRIs Support Many-to-One Relationships]: We’re not replacing the DNS (Domain Naming System). We’re adding a layer of indirection/ abstraction to the existing domain name service. Ultimately, you need the DNS to identify a resource location with which to interact. We’re saying that the resource’s location might change, so you need a layer of semantic interaction. What can change is the human-readable name for this. This is where XNS.org’s other component comes in—it’s what ICAAN is all about. There are three generic namespaces: personal, corporate, and community. The Community area always comes last, because it doesn’t exist in DNS currently. What holds the most interest for the community is the ability of the community to define it’s own memorable name or description of an object; metadata. In the XRI scheme we use EBNF [Extended Backus-Naur Form] to describe this. The specifications are on the XNS website. There’s a 27-line definition in EBNF that describes the rules for describing and cross-referencing identities by name and ID. You can mix an XRI address with identity names and IDs. You can mix and match. If you ever include both, the name becomes the part for human consumption and the ID becomes authoritative. Ultimately, they’re all URIs, so they fit into the REST and Web models.
Slide 25 [The OASIS XRI TC]: So the first step XNS has taken is the naming and addressing conventions for identities. The first step was on December 6 [2002], when the call for participation in an OASIS TC was made. The first meeting is on January 9. I just spoke to Roy Morgan—I believe the first meeting is in San Francisco. I’m going to try to organize something on the East Coast, linked to something on the West Coast. We already know of a few government departments that are interested in participating. I’m meeting with Marion [Royal] on Friday, and maybe we can formalize something. We’ll focus on the URI and URN format of an XNS address, called an XRI (Extensible Resource Identifier). I know Krishna wants to participate, as well as a couple of other companies.
Do you know Winston Bumpus [Novell NDS, DirXML specialist]? We didn’t want to use XRI as the name for the TC, except that XNS was a trademark with which OASIS had an issue. As I have mentioned in this presentation XNS is really a cross-domain directory service. We’re still called XNS, but the first part is going to be called the XRI TC —Winston Bumpus is working with us.
Slide 26 [XNS 1.0: A Two-Part Specification Part 2 – Identity Services]: I’m going to skip over this quickly. The initial idea was a suite of Web Services described in WSDL, but the less you embrace the REST model, the more marginalized you become with the core of the Web Community. The more we distill the XNS Web Services definitions, (WSDL, XSD)—the closer we get to the REST model and the more we realize that they’re well-baked. The XNS Web Services adequately describe the data that are shifted and the messages, but I think most of the work of the XRI TC will be spent on trying to dumb-down the XNS WSDL definitions to the point where we get base services that combine some of the functions here:
· Reading and writing attributes from identity documents
XNS embraces other existing standards where appropriate. For instance, we use SAML— however we use the authentication components of SAML, not the authorization. The authorization in XNS is handled using the XNS XML contract object. This is the start of the journey, not the end of it.
Slide 27 [The XNS WSDL Services Suite]: We are aiming to combine a lot of the lower layer XNS services into a base set compliant with a RESTful model. There are other Services that are not likely to be in the base service, like “Introduction.” We also think that the top layer (the three that are defined currently in the 1.0 specification) will continue as Web Services. These are the three that use SAML assertions. The most significant one that’s coming up is the Reputation service, which is more of an abstract form of assertion. When I looked at XML registry/repository work, I heard the need for the ability to go in and make a reputation assertion about the usefulness of an object published by another identity. It becomes the Dun and Bradstreet, or EBay ratings service. It forms an abstract assertion.
Slide 28 [Treating Identities as XML Documents]: Most of the core ones are easy to grasp. There are in-depth definitions on the XNS website.
Slide 29 [Directory Services at the Identity Layer]: Just a quick one on Directory. We don’t have a decided directory strategy for this. Input would be helpful. We’re thinking that an ebXML registry would be the way to go for this.
Slide 30 [XNS, SAML, and PKI]: XNS uses SAML for the payloads for assertions. In XNS, digital certificates are treated as just another attribute. It’s interesting that when you look at the problems of PKI systems they all become persistent relationship issues. If I have your public key, and I have to keep on going back to the server to see whether it’s revoked, that’s not good. I shouldn’t have to go there each time. It’s similar to the beginnings of credit card usage; clerks had to call a clearinghouse to see whether they were valid. It should be automated.
Slide 31 [Conclusion]: We’re hoping we’ve developed XNS services and XRI addressing that will provide the digital identity infrastructure necessary for Web Services. At the same time, we want to satisfy the REST community that this can satisfy their purposes. The feedback says that this solves some enterprise, cross-domain sharing problems. I encourage you to get involved and help us start the journey.
Mr. Ambur: Has the formation of the TC been announced?
Mr. Le Maitre: Yes. I sent you the email, but I couldn’t find the references to the site.
Mr. Ambur: I first heard about XNS a year ago in the context of XML security initiatives, so I’ve been interested in it for awhile. But my interest was piqued when I got a call from FTC Commissioner Mozelle Thompson inviting me to his office to talk about it. Any updates on the FTC’s consideration of it?
Mr. Le Maitre: One of the biggest concerns was making it open. It was just a week before publishing the specifications that we met with him. We need to get back to him. What really interested them was the ability for the citizen to be empowered about the sharing of his/her own information in a way that the citizen would have evidence of potential wrongdoing. Right now, the FTC waits for others to report a lot of these violations. It comes back to adequate record keeping. Now you have an object that might be digitally signed by a party, which spells out terms of how business is done. It can be modified by either party, depending upon who has control.
What most interested the commission was that it was a mechanism that’s not based on centralized policy, but rather allowed consumer choice. It didn’t’ require prescribed conditions. XNS does not prescribe, “What’s in the container?” It just said, “If you agree to what’s in the container, you have to live by it.” It’s just a record-keeping mechanism. In the XRI TC, we’re probably 3-6 months away from the point where the FTC can say, “That’s what we want.” It focuses initially on the most needed part, which was the naming and addressing.
Mr. Ambur: Any feedback from law enforcement?
Mr. Le Maitre: We talked before the elections. Since then, the foot’s been released from the brake on DOHS. I spoke to Scott Hastings. He’s interested in implementation. Roy, you asked Krishna about where we are on implementation. This thing is emerging as a standard hopefully. Implementation is a way off. Scott wants to see it working. He appreciates that the stovepipe approach is not the way to go, but that we’re still a way off from this being a specification that can be relied upon. As Krishna said, it’ll take time for this to come around—for the community to recognize the problem and work to solve it.
Mr. Ambur: In the meantime, agencies are forced to move forward.
Mr. Le Maitre: Registry/repository is another that’s begging for resolution. The reality is, you have to take baby steps. I just ask that agencies keep moving forward with an eye to the standards, so you don’t move forward on something that would preclude you from taking advantage. If you’re working with Web Services, you’re probably not making wrong decisions. The design challenge is swapping the Web Services when the community agrees on what makes sense.
Mr. Thomas: DNS is open source, but I have to pay yearly to post my domain. I’m not clear on the business model of XNS.org. Is the intention to be at the root of the identity Web?
Mr. Le Maitre: Just as with DNS, there is public and private. DNS you can employ within your own enterprise. It’s when we want to play in the community space that it has to be administered. There are some additional items in XNS that aren’t there in DNS. What we’ve tried to do is bifurcate the namespace to [1] things that can’t have intellectual property associated with them and [2] things that can. XNS brings an opportunity to extend the DNS model in the community namespace. An idea of the business model in the conversation about standards is the idea that registering names for personal or business use is a potential for-profit operation, but when you get into the community namespace, which is anything that can’t be asserted by a person or organization, it’s down to the community to administer. The community namespace ends up being a base level of metadata. The semantic Web suffers from the diversity in the way you describe information. The community namespace in XNS is there to help bootstrap the community. If there’s a community naming problem, the community can create a community name. Community naming is naming you can use anywhere in the community. It’s definitely an opportunity for public resolution of metadata names and it offers much in the way of community services, without the requirement for payment. It takes DNS to where it should have been, to describe data in a way the community can benefit from it.
Mr. Thomas: So I could user the XRI/XSN standards and host my own community with it as the root of my own community.
Mr. Le Maitre: Absolutely. It’s only when you want a public namespace to make use of this that the rights come into play.
Mr. Thomas: If my community wants to interact with XNS.org, there’s a pay model?
Mr. Le Maitre: Yes. None of this is hidden its all on the XNS.org web site. There is a root registrar system with Registrar rules similar to DNS.
Mr. Ken Pittman: There’s another initiative under digital object identifier for authentication, permission, attribution, payment—collaborative scientific efforts.
Mr. Le Maitre: Yes. Handle.
Mr. Ambur: CENDI has scheduled a workshop on Handles for January 29. [Editor’s Note: Information on the workshop is available at http://www2.infointl.com/registration/handles.html]
Mr. Le Maitre: I chatted with our team on the differences from Handle. [Mr. Le Maitre referred to Slide 23 (XRIs Extend the Benefits of URIs and URNs).] We went down these:
· Linked data
and said, “Can Handle do it?” Handle doesn’t provide human-readable, cross-referenceable, or versionable identifiers. It apparently only provides federated identities down to two levels, and doesn’t provide linking of federated data. On the other hand, it’s well-deployed in the book publishing world. We’d be silly not to account for how to build a Handle identifier into XRI, and then you can version it. So there was intent to not reinvent here.
Mr. Ambur: It’s useful to know what handles do and don’t do.
Mr. Le Maitre: Or to talk about it—how they do it, but “not in this way,” or “how it can be built in,” etc.. I don’t want to trash the product.
End presentation
Mr. Ambur: You’ve shared a lot of information with us. The results will speak for themselves in the weeks and months ahead. Bruce [Bargmeyer], David [Heiser], any updates on your projects?
Mr. Bargmeyer: I’ll mention the Open Forum. It’s still going to go on on January 20. You can go to the website and sign up. At XML.gov there’s a link to the Open Forum. People are rapidly signing up. [Editor’s Note: The forum Web site is at http://metadata-stds.org/OpenForum2003/]
Mr. Heiser: On the Section 508 graphics initiative, we’re working with Brand and others. We’re doing research with NIS. There’s no definitive answer at this pint, so we’re going to look for a way to incorporate text description in XML before inserting it in HTML. It’s good for the upcoming EGov initiative on 508.
Mr. Ambur: If there are no more questions or comments, we’ll end with that. Thank you all.
End meeting.
Attendees:
|
Last Name |
First Name |
Organization |
|
Abel |
Elizabeth |
OFHEO |
|
Adams |
Susie |
Microsoft |
|
Ambur |
Owen |
FWS |
|
Bargmeyer |
Bruce |
LBNL |
|
Bellack |
Dena |
LMI |
|
Boyle |
Carrie |
LMI |
|
Church |
Allen |
ASC |
|
Cox |
Bruce |
US PTO |
|
Ghandi |
Ajay |
SIRC |
|
Gutierrez |
Ann |
CSC |
|
Hayes |
Glenda |
MITRE |
|
Heiser |
David |
IRS |
|
Johnson |
Denise |
QRC |
|
Le |
Dyung |
NARA |
|
Le Maitre |
Marc |
OneName |
|
Morgan |
Roy |
NIST |
|
Niemann |
Brand |
EPA |
|
Pittman |
Ken |
BAE Systems |
|
Sall |
Kenneth |
Silosmashers |
|
Sankar |
Krishna |
Cisco |
|
Schuerhoff |
Todd |
CSC |
|
Thomas |
George |
TSA |
|
Turnbull |
Susan |
GSA |
|
Vineski |
Steve |
EPA |
|
Weber |
Lisa |
NARA |
|
Weiland |
John |
NMIMC |
|
Williams |
Kevin |
BlueOxide |
|
Yee |
Theresa |
LMI |