ENUM%20Validation%20Architecture%20

1
ENUM Validation Architecture Token
Formatdraft-mayrhofer-enum-validation-00.txt

• Axel Mayrhofer, Otmar Lendl
• enum.at GmbH
• Michael Haberler
• Internet Foundation Austria

2
overview

• sources of validation information
• goals setup options
• architecture
• token format contents

3
sources of validation information
source case count likelihood of participation quality
service provider (ITSP/Telco) potentially high initially low
porting process/NPAC varying high
user (direct assignment) low high
directory assistance operators high conceivable /-
dedicated validation SP low high - ..
centralized validation agency high high ? / cost!!
4
goals

• prove the registrants right-to-use in the number
• efficient process in common cases
• be easy on incumbents or theyll never bite
• allow for consumer choice
• enable ENUM service provision even if NRH is not
  cooperating
• avoid the next monopoly
• allow for many sources of validation information
• may the best method win
• dont tilt new versus existing number use

5
setup options

• centralized validation agent
• this is the next monopoly
• inefficient on service providers they know
  their customers already
• multiple validation agents
• no monopoly, but still ineffective
• number range holder registrar
• efficient on telcos, ITSPs
• might leave consumer behind
• conclusion no single source works best
• so define Validation Entity as a role
• VE might collapse with registrar easy
• it might not a chain of trust is required

6
architecture
registration validation token
validation request
validation entity
registrar
validation token
delegation request
registrant
7
validation process

• requires a chain of trust registry lt-gt VE
• signing of token with XML-DSIG certificate
• contract between VE and registry
• assigns ID, describes method, trust chain
• open list of methods
• regulatory requirement in 43 is by maximum
  failure rate only
• token lifetime determines the domain visibility
• token contents is an audit trail

8
token contents

• token MUST contain
• validation serial number
• e164 number
• validation entity ID
• method ID
• registrar for whom validation was carried out
• create, expiredate
• MAY contain
• registrant identity
• organisation
• commercial entity registration number
• title, firstname, lastname, address, streetname,
  streetnumber, apt,zip code, country, state
• phone, fax, email
• identity geared towards reuse of directory
  information as per ITU E.115
• a superset of the hoeneisen-token

9
contacts

• Alexander Mayrhofer enum.at GmbH Phone 43 1
  5056416 34 alexander.mayrhofer_at_enum.at
• Otmar Lendl enum.at GmbH Phone [phone]
  33 otmar.lendl_at_enum.at
• Michael Haberler Internet Foundation Austria
  phone [phone] mah_at_eunet.at
• registry specification, registrar manual,
  registrar toolkit, contracts available at
  www.enum.at