The Identity Web Overview of the XNS Technical Specifications

1
The Identity WebOverview of the XNS Technical
Specifications

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

2
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

3
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

4
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

5
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

6
Motivations for XNSORG

• OneNames 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
  wasnt yet understood
• An infrastructure like XNS required open,
  community governance (e.g., ICANN)
• There was no Liberty!

7
Architectural Model
8
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

9
Evolution of Web identity (step 1)
Web Servers
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 Pages(HTML)
Millions of files were available on
Internet-connected enterprise file servers but
there was no common way to view, access, or link
them.
Content
10
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
Web Pages(HTML)
Transactions
Content
11
Evolution of Web identity (step 3)
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
Identity Servers
Web Identities(XML)
Web Pages(HTML)
Transactions
Content
12
Identity linking
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.
Identity Server
Identity Server
Identity Document
Identity Document
Identity Attributes
Identity Attributes
Each link with another identity is defined by a
subdocument inside the identity document.
Link
Link
Contract
Contract
IdentityLink
Permissions
Permissions
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.
Contract
Contract
Permissions
Permissions
Links create trusted, bidirectional data pipes
between any two XNS identities anywhere.
13
Web identity services architecture
Browser
Browser
Identity
Application
WebIdentityRoot
Logical
Web (HTML over HTTP)
Web Services (XML over SOAP)
Web Identity Services (XNS over SOAP)
Enterprise Security
Enterprise Security
Enterprise Security
Enterprise Directory
Enterprise Directory
Enterprise Directory
Enterprise Integration
Enterprise Integration
Enterprise Integration
Application
Physical
Application
Application
Persistence
Persistence
Persistence
EnterpriseIdentityRoot
Domain
Domain
Domain
14
XNS Services by Category
15
The XNS base services
AttributeManagementServices
CredentialManagementServices
Exchange LinkingServices
Reputation
Introduction
Directory
Higher-level services
Folder
Certification
Data
Negotiation
Session
Hosting
Discovery
Authentication
Core
Name
URNServices
ID
Foundation services
Resolution
Not in XNS 1.0 specifications
16
URN Services
AttributeManagementServices
CredentialManagementServices
Exchange LinkingServices
Reputation
Introduction
Directory
Higher-level services
Folder
Certification
Data
Negotiation
Session
Hosting
Discovery
Authentication
Core
Name
URNServices
ID
Foundation services
Resolution
Not in XNS 1.0 specifications
17
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 dont break when the attributes of an
  identity change

18
Name Service and ID Service
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
SemanticName
SemanticName
Attribute
Persistent ID(URN)
In a name service like DNS, names reference
attributes directly, so if a name changes,
references break.
Attribute
19
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)

20
Attribute Management Services
AttributeManagementServices
CredentialManagementServices
Exchange LinkingServices
Reputation
Introduction
Directory
Higher-level services
Folder
Certification
Data
Negotiation
Session
Hosting
Discovery
Authentication
Core
Name
URNServices
ID
Foundation services
Resolution
Not in XNS 1.0 specifications
21
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

22
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)

23
Credential Management Services
AttributeManagementServices
CredentialManagementServices
Exchange LinkingServices
Reputation
Introduction
Directory
Higher-level services
Folder
Certification
Data
Negotiation
Session
Hosting
Discovery
Authentication
Core
Name
URNServices
ID
Foundation services
Resolution
Not in XNS 1.0 specifications
24
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

25
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.)

26
Exchange and Linking Services
AttributeManagementServices
CredentialManagementServices
Exchange LinkingServices
Reputation
Introduction
Directory
Higher-level services
Folder
Certification
Data
Negotiation
Session
Hosting
Discovery
Authentication
Core
Name
URNServices
ID
Foundation services
Resolution
Not in XNS 1.0 specifications
27
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

28
Contract structure
A link object can contain any number of contract
objects covering different data purposes.
Identity Document
Link (one per relationship)
Each contract states the terms, purpose, and
applicable policies (policy references use URNs).
Contract (one per agreement)
General Terms
Contracts reference the attributes they cover
using URNs.
Purpose
Policy 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.
Attribute references
Permissions
Signature
Contracts are signed and stored by both parties
for auditing and non-repudiation.
29
Permission objectsprivacy and security controls
Permission
SynchronizationPermission
PrivacyPermission

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

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

30
The negotiation process
Service Provider
Identity Provider
1) The SP sends an XNS form definition
(essentially a template contact) to the IDP.
Identity Document
Identity Document
Attributes
Attributes
Policies
Preferences
2) The IDP processes the form based on the
principals attributes and preferences and
negotiates the contract.
Schema Def
1
Form Def
2
3
Link
Link
Identity Link
Contract
Contract
3) Both parties sign the contract and store a
copy in their link.
Permissions
Permissions
31
The synchronization process
Identity Provider
Service Provider
1) When the principal updates an attribute, the
IDP checks to see which contracts reference that
attribute.
Identity Document
Identity Document
Attributes
Attributes
Attribute 1
2) If the contract specifies a push, the
publishing identity composes an XNS Set message
and attaches a SAML assertion.
Attribute 2
Attribute 2
1
3
Link
Link
Contract
Contract
3) The subscribing SP authenticates the message
and writes the updated attribute.
Permissions
Permissions
2
32
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

33
XNS in the SOAP Stack
34
XNS serves a function parallel to DNS
XNS is an iden-tity service for the endpoints of
web services (SOAP actors)
WSDL-based Web Services
Higher-level protocols
XNS
Baseprotocol
SOAP
Application-to-Application Layer (XML Messages)
DNS is a name service for the endpoints of TCP/IP
protocols (domains hosts)
Telnet, FTP, SMTP, HTTP, etc.
Higher-level protocols
DNS
Baseprotocol
TCP/IP
Machine-to-Machine Layer (Packets)
35
The SOAP stack with XNS
WSCL
ebXML
XLANG
WSFL
BTP
Service Interaction Orchestration
ebXML RR
UDDI
Business Registry
XKMS
XRML
XML Encryption
XML Signature
SAML
Security
WS-Security
?
Security Protocols
WS-Inspection
WSDL
Service Description
WS-Routing
Intermediary and Endpoint Services
XNS
DIME
WS-Reliability
HTTPR
BXXP
ebXML TRP
Transport Services Encapsulation Reliability
SOAP v1.1
SOAP v1.2
DIME SOAP
SOAP w/Attachs
Messaging Protocols
HTTP
HTTPS
IIOP/S
FTP
SMTP
UDP
MQ
JMS
Transport Protocol
Source IONA SOAP Interop website
(http//www.xmlbus.com/interop/img/SoapBuildersInt
eropRoadmap.gif)