idnits 2.17.1 draft-wendt-modern-identity-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 217 has weird spacing: '...type_id strin...' == Line 221 has weird spacing: '...vice_id str...' == Line 242 has weird spacing: '... 5xx erro...' == Line 249 has weird spacing: '...ting_id stri...' == Line 315 has weird spacing: '...vice_id str...' == (2 more instances...) -- The document date (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-wendt-modern-drip-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 modern C. Wendt 3 Internet-Draft Comcast 4 Intended status: Standards Track March 13, 2017 5 Expires: September 14, 2017 7 Identity Registry (idreg) 8 draft-wendt-modern-identity-registry-01 10 Abstract 12 This document will describe an approach for how a distributed 13 identity registry model might look. It will consider both public 14 registry components of the data model necessary for routing calls 15 from one globally routable identity to another. It will also 16 consider part of the private registry components a provider may need 17 to manage associations with users or customers. Other topics include 18 provider associations, application or service association, and the 19 ability to support multiple identities associated with a user/ 20 subscriber (e.g. telephone number and e-mail identity). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 14, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Identity Data Model . . . . . . . . . . . . . . . . . . . 3 60 3.2. Other identity registry attributes . . . . . . . . . . . 4 61 4. Message and Control Flows . . . . . . . . . . . . . . . . . . 5 62 4.1. Queries . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Allocation/Assignment . . . . . . . . . . . . . . . . . . 5 64 4.2.1. API definition . . . . . . . . . . . . . . . . . . . 5 65 4.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. Update Entry/Port . . . . . . . . . . . . . . . . . . . . 7 67 4.3.1. API definition . . . . . . . . . . . . . . . . . . . 7 68 4.4. Removal/de-allocation . . . . . . . . . . . . . . . . . . 8 69 4.4.1. API definition . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 There are many useful VoIP and user to user communications 80 applications that desire the ability to provide services that don't 81 depend on a single entity or provider to manage the end-to-end 82 identities associated with that application. For example, using the 83 VoIP protocol, SIP [RFC3261], the telephone network provides a 84 federated mechanism that using a publicly known identity, the 85 telephone number, a customer of a telephone provider A can call a 86 customer of telephone provider B based on managed routing databases 87 and routing rules. XMPP [RFC6120] is another example of a protocol 88 that allowed federation of communications based on the username and 89 domain of the host of the XMPP server. Each of these examples uses 90 service specific databases or registries that are generally protocol 91 or application specific, however today application providers general 92 provide many applications or services for a user which generally 93 share the use of common communications identities like telephone 94 numbers, e-mail identities, or identities associated with web based 95 IdPs. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. Overview 105 The identity registry model proposed in this document supports the 106 model where there are a few actors in the model relevant to providing 107 communications services. 109 o Provider - An entity that provide a service to customers and 110 manages there identity in the network. 112 o User/Subscriber - The entity that is using the services of the 113 provider. 115 o Service Identity - A globally unique identifier representing a 116 application or service being made available to users/subscribers 117 by multiple providers. 119 o Public Identity - A publicly known identity that the user 120 associates with a service. This identity must be globally unique 121 to a user/subscriber. It must also be provably associated to a 122 given user/subscriber that claims the association. 124 o Routing Identity - A uniquely and globally routable identity used 125 specifically in signaling calls between users. 127 This data model can be used to build the shared data between 128 providers that support the federated service in order for users that 129 are associated with one provider to call another provider. 131 3.1. Identity Data Model 132 ___________ 133 | | 134 | User/ |\ 135 | Subscriber| \ 136 | (Private) | \ 137 |___________| Uses Services of 138 | ___\_______ 139 | | | 140 Subscribes to | Provider | 141 | |__________| 142 _____|_____ / 143 | | Offers a 144 | Service | / 145 | Identity |/ 146 |___________| 147 | 148 | 149 Using (one or more) 150 | 151 _________________|___________________ 152 _____|_____ _____|_____ _____|_____ 153 | | | | | | 154 | Public | | Public | | Public | 155 | Identity 1| | Identity 2| ... | Identity N| 156 |___________| |___________| |___________| 157 |________________|__________________| 158 | 159 is network addressable by 160 ____|_____ 161 | | 162 | Routing | 163 | Identity | 164 |__________| 166 3.2. Other identity registry attributes 168 The identity registry MUST support functions such as the following: 170 o The ability to query for available/unused identities for the 171 purposes of either identifying conflicts before committing to the 172 registry or identify unused identities that are part of a pool 173 (e.g. telephone numbers) 175 o The ability to allocate identities for future use at individual 176 levels or at block levels, such as NPA-NXX level telephone numbers 177 or perhaps wildcard identities, e.g. *@example.com. 179 o The ability to update/transfer/port identities from one provider 180 to another provider. 182 o The ability to digitally sign transactions to a provider for 183 validation of legitimate transactions. Or forensic analysis of 184 illegitimate transactions. 186 It is anticipated that this identity registry would be used with 187 [I-D.wendt-modern-drip] for supporting a continuously and timely 188 updated local registry for a given service identity the provider is 189 offering. 191 4. Message and Control Flows 193 4.1. Queries 195 Typical queries for finding a globally routable identity should be in 196 the context of a public identity and service identity for an 197 allocated routing identity. 199 4.2. Allocation/Assignment 201 When a provider customer has decided to allocate a given single or 202 block level set of telephone numbers there is a PUT command that 203 allocates the number, given the number wasn't already allocated 204 between the GET and the PUT. As a result of a successful allocation, 205 the telephone number will be removed from the unallocated bucket. 207 4.2.1. API definition 208 Request: 209 PUT /idreg/createidentity 211 Pass the following object (JSON) in the body. 213 --------------------------------------------------------------- 214 Property Type Description 215 --------------------------------------------------------------- 216 user_type string (MAND) Type representing user/sub 217 user_type_id string (MAND) ID associated with user 218 Example: accountID of user 219 user_info stringified (OPT) User specific metadata 220 JSON 221 service_id string (MAND) Service type identifier 222 Example: "pstn", "voip". "volte" 223 public_id string (MAND) User associated service 224 identifier. Example: telephone 225 number 227 An Authorization Header MUST be included with a JWT including 228 timestamp, x5u, and signature that will be associated with this 229 transaction. 231 Response: 232 --------------------------------------------------------------- 233 Code Status 234 --------------------------------------------------------------- 235 201 user profile created, associate public id, 236 returns new routing ID 237 200 user profile and public id association already exists 238 returns the same routing ID (Idempotent) 239 204 service identifier not found 240 400 input errors 241 401 unauthorized API access - Signature validation failed 242 5xx errors related to DB access and other system anomalies 244 For HTTP/1.1 200 OK and HTTP/1.1 201 Created responses: 245 ---------------------------------------------------------------- 246 Property Type Description 247 ---------------------------------------------------------------- 248 user_id string Globally Unique ID (UUID) for user. 249 routing_id string routing ID 251 4.2.2. Example 253 As part of the allocation, the service provider will be required to 254 provide following information: 256 o publicID: telephone number in e.164 format (e.g., +12155551212). 258 o serviceID: "voip" by default, other services potentially in 259 future. 261 o routingID: SIP URI with telephone number + domain representing 262 service provider of record (e.g., 263 sip:+12155551212@voip.example.com). 265 o timestamp: a timestamp retrieved from a common NTP server 266 representing time of allocation, used for validating which service 267 provider allocated first in race condition scenarios, and just for 268 logging and historical reference in general. 270 o x5u: used for validation of signature 272 o signature: using a provider level [RFC5280] based private key/ 273 certificate, the provider MUST sign the information above to 274 validate the change to the registry. 276 4.3. Update Entry/Port 278 If a provider needs to update information related to an allocated 279 entry, such as adding a publicID, modify routingID, etc. or if there 280 is a port where a new service provider will overwrite the entry with 281 new information, the API should be the same. 283 There is a GET operation to read the current entry information, if 284 the provider needs this information, (e.g., read/modify/write). 285 There also is a PUT operation that will write the updated entry 286 information. This will require a new timestamp and signature to 287 validate the security of the operation and logging/historical 288 purposes. 290 4.3.1. API definition 292 The PUT /idreg/createidentity API can be used for updates to entries 293 as it's an idempotent API. For porting of telephone numbers either 294 createidentity or a combination of the delete described in the next 295 section and createidentity can be used. 297 4.4. Removal/de-allocation 299 If a provider wants to remove an entry for the case where a customer 300 removes his service and no longer wants to own or associate a public 301 identity, a DELETE operation will be provided that will delete the 302 entry, and for the case of a telephone number, will put the telephone 303 number back in the pool of unallocated numbers. 305 4.4.1. API definition 307 Request: 308 DELETE /idreg/identitymapping/serviceid/:id/publicid/:id 310 Pass the following object (JSON) in the body. 312 --------------------------------------------------------------- 313 Property Type Description 314 --------------------------------------------------------------- 315 service_id string (MAND) Service type identifier 316 Example: "pstn", "voip". "volte" 317 public_id string (MAND) User associated service 318 identifier. Example: telephone 319 number 321 An Authorization Header MUST be included with a JWT including 322 timestamp, x5u, and signature that will be associated with this 323 transaction. 325 Response: 326 --------------------------------------------------------------- 327 Code Status 328 --------------------------------------------------------------- 329 200 public ID association deleted 330 204 record with service_id and public_id in request URI not 331 found 332 400 input errors 333 401 unauthorized API access - Signature validation failed 334 5xx errors related to DB access and other system anomalies 336 For HTTP/1.1 200 OK and HTTP/1.1 201 Created responses: 337 ---------------------------------------------------------------- 338 Property Type Description 339 ---------------------------------------------------------------- 340 user_id string Globally Unique ID (UUID) for user. 341 routing_id string routing ID 343 5. Security Considerations 345 TBD 347 6. Acknowledgements 349 Thanks to Harsha Bellur for collaboration on developing this model 350 and it's implementation. 352 7. References 354 7.1. Normative References 356 [I-D.wendt-modern-drip] 357 Bellur, H. and C. Wendt, "Distributed Registry Protocol", 358 draft-wendt-modern-drip-01 (work in progress), July 2016. 360 7.2. Informative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 368 A., Peterson, J., Sparks, R., Handley, M., and E. 369 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 370 DOI 10.17487/RFC3261, June 2002, 371 . 373 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 374 Housley, R., and W. Polk, "Internet X.509 Public Key 375 Infrastructure Certificate and Certificate Revocation List 376 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 377 . 379 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 380 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 381 March 2011, . 383 Author's Address 384 Chris Wendt 385 Comcast 386 One Comcast Center 387 Philadelphia, PA 19103 388 USA 390 Email: chris-ietf@chriswendt.net