# Presentation: 491189

## The Identity WebOverview of the XNS Technical Specifications

- Update for XML Working GroupJune 24, 2002
- Marc Le Maitre - XNSORG

## Topics presented in this paper

- Background & Motivations for XNS and XNSORG
- Architectural Model for the Identity Web
- Identity Services by Category
- XNS as a set of Web Services in the SOAP Stack

## Background

- eXtensible Name Service (XNS) originated in 1999 as a “DNS for identity”
- OneName licensed it to the XNS Public Trust Organization (XNSORG) in Sept. 2000
- Many companies were attracted by its potential to solve Web-wide identity problems
- But changes were necessary
- Iterations on the technical specifications
- XNSORG licensing and governance changes

## Background (2)

- In Sept. 2001 specifications were all moved to Web services standards (WSDL)
- Five revision cycles since then
- Sponsor companies began working with OneName and XNSORG to revise the license and charter
- All business terms were agreed to in March; the final legal documents are in process now
- On July 8th 2002 the 1.0 specs will be available under an open royalty-free license

## Motivations for XNS

- To solve longstanding Internet infrastructure problems involving the exchange of private information, i.e., identity, security, and privacy
- To do so using a language-, platform-, and vendor-neutral open protocol modeled after the Web protocols (i.e., HTML, HTTP, URLs)
- To do so using a fully distributed, federated architecture like DNS
- To provide an open platform for Web identity management

## Motivations for XNSORG

- OneName’s IPR needed to be contributed to an open protocol
- In 2000, it was too early and too ambitious for the major standards bodies (W3C, OASIS)
- It was pre-Web services so the architecture wasn’t yet understood
- An infrastructure like XNS required open, community governance (e.g., ICANN)
- There was no Liberty!

## Architectural Model

## A Web services approach

- XNS is a collection of 12 Web services for identity and relationship management plus a URN specification
- As with Web services in general, this is fundamentally a peer-to-peer model
- The ultimate model is the Web itself
- The World Wide Web links content documents
- The “Identity Web” links identity documents

## Evolution of Web identity (step 1)

- Millions of files were available on Internet-connected enterprise file servers but there was no common way to view, access, or link them.

- The force that drove the Web was the elevation of content to a logical level of representation (HTML) and access (HTTP). Now it could be linked (using URIs) across Web servers regardless of the physical system on which it was stored. The rest is history.

**Web Servers**

**Web Pages****(HTML)**

*Content*

## Evolution of Web identity (step 2)

- Today enterprise identity is in the same predicament as enterprise content was ten years ago. It is constrained by the hierarchical organization and administrative control of enterprise directory servers. Sharing identity across domains is as difficult as sharing files across domains was in 1990.

**Web Servers**

*Transactions*

*Content*

**Web Pages****(HTML)**

## Evolution of Web identity (step 3)

*Transactions*

- By abstracting identity to the logical level (XML), Web identity documents and identity servers solve the problem of identity sharing the same way the Web solved the problem of content sharing. In addition, Web identity can leverage the logical HTML viewing layer provided by the Web.

**Web Servers**

*Content*

**Identity Servers**

**Web Identities****(XML)**

**Web Pages****(HTML)**

## Identity linking

**Identity Server**

**Identity Document**

**Identity Attributes**

**Link**

**Contract**

**Permissions**

**Contract**

**Permissions**

**Identity Server**

**Identity Document**

**Identity Attributes**

**Link**

**Contract**

**Permissions**

**Contract**

**Permissions**

**Identity****Link**

- Identity servers host XML documents representing attributes associated with an identity. These documents can be “virtual”, i.e., the physi-cal data can be stored in lower-layer systems.

- Each link with another identity is defined by a subdocument inside the identity document.

- A link can contain any number of contracts, each defining a set of data shared with the other identity and the applicable security, privacy, and synchro-nization permissions.

- Links create trusted, bidirectional data “pipes” between any two XNS identities anywhere.

## Web identity services architecture

**Enterprise Integration**

**Enterprise Security**

**Enterprise Directory**

**Persistence**

**Application**

**Web Services (XML over SOAP)**

**Browser**

**Web (HTML over HTTP)**

**Web Identity Services (XNS over SOAP)**

*Physical*

*Logical*

**Enterprise Integration**

**Enterprise Security**

**Enterprise Directory**

**Persistence**

**Application**

**Enterprise Integration**

**Enterprise Security**

**Enterprise Directory**

**Persistence**

**Application**

**Browser**

**Identity**

**Application**

- Domain

- Domain

- Domain

- EnterpriseIdentityRoot

- WebIdentityRoot

## XNS Services by Category

## The XNS base services

**Negotiation**

**Reputation***

**Certification**

**Session**

**Authentication**

**Introduction***

**Folder**

**Name**

**ID**

**Resolution**

**Hosting**

**Data**

**Discovery**

**Core**

**Directory***

**URN****Services**

**Attribute****Management****Services**

**Credential****Management****Services**

**Exchange & Linking****Services**

**Foundation services**

**Higher-****level services**

- * Not in XNS 1.0 specifications

## URN Services

**Negotiation**

**Reputation***

**Certification**

**Session**

**Authentication**

**Introduction***

**Folder**

**Name**

**ID**

**Resolution**

**Hosting**

**Data**

**Discovery**

**Core**

**Directory***

**URN****Services**

**Attribute****Management****Services**

**Credential****Management****Services**

**Exchange & Linking****Services**

**Foundation services**

**Higher-****level services**

- * Not in XNS 1.0 specifications

## URN Services (2)

- The purpose of URNs is to provide persistent addresses (see IETF RFC 2141)
- URLs are current locators which may break if a name changes or a resource moves on the network
- An Identity Web requires references and links that don’t break when the attributes of an identity change

## Name Service and ID Service

**Semantic****Name**

**Attribute**

**Semantic****Name**

**Persistent ID****(URN)**

**Attribute**

- In a name service like DNS, names reference attributes directly, so if a name changes, references break.

- In an identity service like XNS, names reference IDs (URNs) which never change. So when a name changes, a reference based an underlying URN will not break. Many semantic names can be mapped to a persistent ID allowing the generation of “randomized” names that protect pseudonymity or anonymity

## Resolution Service

- The base resolution service in XNS
- Accepts any form of an XNS address according to the XNS Addressing Spec EBNF
- XNS Name
- XNS ID (URN)
- Mixed forms
- Resolves the address to the network endpoint for the identity provider (URL)

## Attribute Management Services

**Negotiation**

**Reputation***

**Certification**

**Session**

**Authentication**

**Introduction***

**Folder**

**Name**

**ID**

**Resolution**

**Hosting**

**Data**

**Discovery**

**Core**

**Directory***

**URN****Services**

**Attribute****Management****Services**

**Credential****Management****Services**

**Exchange & Linking****Services**

**Foundation services**

**Higher-****level services**

- * Not in XNS 1.0 specifications

## Attribute Management Services (2)

- The set of services needed to manage an identity document, i.e., the DOM interface to any identity
- Core service defines the abstract schemas and XML complex types used by all other XNS services – it has no messages
- Discovery service defines the XNS metaschema vocabulary and provides messages for querying for service availability, service definitions, and service endpoints

## Attribute Management Services (3)

- Hosting service is for creating and deleting identity documents
- Data service is for getting and setting identity attributes (complex or simple)
- Folder service is for organizing attributes and profiles hierarchically (like file tree organization)
- Directory (future) will allow for hierarchical organization of identity documents themselves (i.e., taxonomies)

## Credential Management Services

**Negotiation**

**Reputation***

**Certification**

**Session**

**Authentication**

**Introduction***

**Folder**

**Name**

**ID**

**Resolution**

**Hosting**

**Data**

**Discovery**

**Core**

**Directory***

**URN****Services**

**Attribute****Management****Services**

**Credential****Management****Services**

**Exchange & Linking****Services**

**Foundation services**

**Higher-****level services**

- * Not in XNS 1.0 specifications

## Credential Management Services (2)

- Credentials are just a special type of attribute used to form trust relationships
- XNS credential management services define special messages for obtaining or asserting these attributes
- In XNS 1.0, the “payload” inside each XNS credential management message is a SAML assertion

## Credential Management Services (3)

- Authentication service creates, manages, and verifies authentication assertions
- Session service manages authentication assertions across authentication domains
- Certification service manages the creation, distribution, and revocation of digital certificates
- Reputation (future) will handle link attribute assertions (credit ratings, eBay ratings, etc.)

## Exchange and Linking Services

**Negotiation**

**Reputation***

**Certification**

**Session**

**Authentication**

**Introduction***

**Folder**

**Name**

**ID**

**Resolution**

**Hosting**

**Data**

**Discovery**

**Core**

**Directory***

**URN****Services**

**Attribute****Management****Services**

**Credential****Management****Services**

**Exchange & Linking****Services**

**Foundation services**

**Higher-****level services**

- * Not in XNS 1.0 specifications

## Exchange and Linking Services (2)

- Negotiation service is the “hero” service in XNS – the one that does all the work
- Negotiation service handles the setup and maintenance of all identity relationships
- Negotiation always results in a link between identity documents containing 1+ contracts
- Contracts are the universal permission, delegation and authorization mechanism in XNS because they model control relationships

## Contract structure

**Identity Document**

**Link **(one per relationship)

**Contract **(one per agreement)

**Attribute references**

**Permission objects are extensible to model any type of privacy policy (opt-out, opt-in, opt-over) in any legal jurisdiction. They also cover access control and synchronization.**

**Purpose**

**General Terms**

**Policy references**

**Permissions**

**Signature**

**A link object can contain any number of contract objects covering different data & purposes.**

**Each contract states the terms, purpose, and applicable policies (policy references use URNs).**

**Contracts reference the attributes they cover using URNs.**

**Contracts are signed and stored by both parties for auditing and non-repudiation.**

## Permission objects:privacy and security controls

**Permission**

**Synchronization****Permission**

- Controls:
-  Permission type (disclosure, contact, retention)
-  Purpose (human-readable)
-  Parties (for disclosure)

**Privacy****Permission**

- Controls:
-  Sync type (push-with-data, push-notification-only, pull-on-demand)
-  Full or incremental
-  Channel security parameters

## The negotiation process

**Service Provider**

**Identity Document**

**Attributes**

**Identity Provider**

**Identity Document**

**Attributes**

**Link**

**Contract**

**Permissions**

**1) The SP sends an XNS form definition (essentially a template contact) to the IDP.**

**3) Both parties sign the contract and store a copy in their link.**

**2) The IDP processes the form based on the principal’s attributes and preferences and negotiates the contract.**

**Policies**

**Schema Def**

**Form Def**

**Link**

**Contract**

**Permissions**

**Identity ****Link**

**1**

**2**

**3**

**Preferences**

## The synchronization process

**Identity Provider**

**Identity Document**

**Attributes**

**Service Provider**

**Identity Document**

**Attributes**

**Link**

**Contract**

**Permissions**

**1) When the principal updates an attribute, the IDP checks to see which contracts reference that attribute.**

**2) If the contract specifies a push, the publishing identity composes an XNS Set message and attaches a SAML assertion.**

**3) The subscribing SP authenticates the message and writes the updated attribute.**

**Attribute 1**

**Attribute 2**

**1**

**Link**

**Contract**

**Permissions**

**2**

**3**

**Attribute 2**

## Privacy and security compliance

- XNS was explicitly designed to implement the requirements of the ISTPA Global Privacy Framework (www.istpa.org)
- It was also designed to meet the requirements of the EU Data Directive
- An XNS implementation has already been deployed to meet U.S. GLBA compliance
- Several implementations are planned to meet U.S. HIPPA privacy/security requirements

## XNS in the SOAP Stack

## XNS serves a function parallel to DNS

**XNS serves a function parallel to DNS**

**SOAP**

**XNS**

- Telnet, FTP, SMTP, HTTP, etc.

- Baseprotocol

- Higher-level protocols

**DNS is a name service for the endpoints of TCP/IP protocols (domains & hosts)**

**XNS is an iden-tity service for the endpoints of web services (SOAP actors)**

**Machine-to-Machine Layer (Packets)**

**Application-to-Application Layer (XML Messages)**

**TCP/IP**

**DNS**

- Baseprotocol

- Higher-level protocols

## The SOAP stack with XNS

- WS-Security

- WS-Inspection

- WS-Routing

- DIME

- SOAP v1.1

- HTTP

- HTTPS

- IIOP/S

- FTP

- SMTP

- UDP

- MQ

- JMS

- SOAP v1.2

- DIME SOAP

- SOAP w/Attach’s

- WS-Reliability

- HTTPR

- BXXP

- ebXML TRP

- WSDL

- ?

- XKMS

- XRML

- XML Encryption

- XML Signature

- SAML

- ebXML RR

- UDDI

- WSCL

- ebXML

- XLANG

- WSFL

- BTP

- Transport Protocol

- Messaging Protocols

- Transport Services –Encapsulation & Reliability

**Intermediary and ****Endpoint Services**

- Service Description

- Security Protocols

- Security

- Business Registry

- Service Interaction & Orchestration

**XNS**

*Source: IONA SOAP Interop website (http://www.xmlbus.com/interop/img/SoapBuildersInteropRoadmap.gif) *