[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

modern                                                          C. Wendt
Internet-Draft                                                   Comcast
Intended status: Standards Track                          March 13, 2017
Expires: September 14, 2017


                       Identity Registry (idreg)
                draft-wendt-modern-identity-registry-01

Abstract

   This document will describe an approach for how a distributed
   identity registry model might look.  It will consider both public
   registry components of the data model necessary for routing calls
   from one globally routable identity to another.  It will also
   consider part of the private registry components a provider may need
   to manage associations with users or customers.  Other topics include
   provider associations, application or service association, and the
   ability to support multiple identities associated with a user/
   subscriber (e.g. telephone number and e-mail identity).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Wendt                  Expires September 14, 2017               [Page 1]


Internet-Draft                    idreg                       March 2017


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Identity Data Model . . . . . . . . . . . . . . . . . . .   3
     3.2.  Other identity registry attributes  . . . . . . . . . . .   4
   4.  Message and Control Flows . . . . . . . . . . . . . . . . . .   5
     4.1.  Queries . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Allocation/Assignment . . . . . . . . . . . . . . . . . .   5
       4.2.1.  API definition  . . . . . . . . . . . . . . . . . . .   5
       4.2.2.  Example . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Update Entry/Port . . . . . . . . . . . . . . . . . . . .   7
       4.3.1.  API definition  . . . . . . . . . . . . . . . . . . .   7
     4.4.  Removal/de-allocation . . . . . . . . . . . . . . . . . .   8
       4.4.1.  API definition  . . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   There are many useful VoIP and user to user communications
   applications that desire the ability to provide services that don't
   depend on a single entity or provider to manage the end-to-end
   identities associated with that application.  For example, using the
   VoIP protocol, SIP [RFC3261], the telephone network provides a
   federated mechanism that using a publicly known identity, the
   telephone number, a customer of a telephone provider A can call a
   customer of telephone provider B based on managed routing databases
   and routing rules.  XMPP [RFC6120] is another example of a protocol
   that allowed federation of communications based on the username and
   domain of the host of the XMPP server.  Each of these examples uses
   service specific databases or registries that are generally protocol
   or application specific, however today application providers general
   provide many applications or services for a user which generally
   share the use of common communications identities like telephone
   numbers, e-mail identities, or identities associated with web based
   IdPs.




Wendt                  Expires September 14, 2017               [Page 2]


Internet-Draft                    idreg                       March 2017


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Overview

   The identity registry model proposed in this document supports the
   model where there are a few actors in the model relevant to providing
   communications services.

   o  Provider - An entity that provide a service to customers and
      manages there identity in the network.

   o  User/Subscriber - The entity that is using the services of the
      provider.

   o  Service Identity - A globally unique identifier representing a
      application or service being made available to users/subscribers
      by multiple providers.

   o  Public Identity - A publicly known identity that the user
      associates with a service.  This identity must be globally unique
      to a user/subscriber.  It must also be provably associated to a
      given user/subscriber that claims the association.

   o  Routing Identity - A uniquely and globally routable identity used
      specifically in signaling calls between users.

   This data model can be used to build the shared data between
   providers that support the federated service in order for users that
   are associated with one provider to call another provider.

3.1.  Identity Data Model
















Wendt                  Expires September 14, 2017               [Page 3]


Internet-Draft                    idreg                       March 2017


                             ___________
                            |           |
                            |   User/   |\
                            | Subscriber|  \
                            | (Private) |    \
                            |___________|    Uses Services of
                                  |           ___\_______
                                  |           |          |
                            Subscribes to     | Provider |
                                  |           |__________|
                             _____|_____       /
                            |           |  Offers a
                            | Service   |  /
                            | Identity  |/
                            |___________|
                                  |
                                  |
                          Using (one or more)
                                  |
                 _________________|___________________
            _____|_____      _____|_____        _____|_____
           |           |    |           |      |           |
           |  Public   |    |  Public   |      |  Public   |
           | Identity 1|    | Identity 2|  ... | Identity N|
           |___________|    |___________|      |___________|
                 |________________|__________________|
                                  |
                       is network addressable by
                              ____|_____
                             |          |
                             | Routing  |
                             | Identity |
                             |__________|


3.2.  Other identity registry attributes

   The identity registry MUST support functions such as the following:

   o  The ability to query for available/unused identities for the
      purposes of either identifying conflicts before committing to the
      registry or identify unused identities that are part of a pool
      (e.g. telephone numbers)

   o  The ability to allocate identities for future use at individual
      levels or at block levels, such as NPA-NXX level telephone numbers
      or perhaps wildcard identities, e.g. *@example.com.




Wendt                  Expires September 14, 2017               [Page 4]


Internet-Draft                    idreg                       March 2017


   o  The ability to update/transfer/port identities from one provider
      to another provider.

   o  The ability to digitally sign transactions to a provider for
      validation of legitimate transactions.  Or forensic analysis of
      illegitimate transactions.

   It is anticipated that this identity registry would be used with
   [I-D.wendt-modern-drip] for supporting a continuously and timely
   updated local registry for a given service identity the provider is
   offering.

4.  Message and Control Flows

4.1.  Queries

   Typical queries for finding a globally routable identity should be in
   the context of a public identity and service identity for an
   allocated routing identity.

4.2.  Allocation/Assignment

   When a provider customer has decided to allocate a given single or
   block level set of telephone numbers there is a PUT command that
   allocates the number, given the number wasn't already allocated
   between the GET and the PUT.  As a result of a successful allocation,
   the telephone number will be removed from the unallocated bucket.

4.2.1.  API definition






















Wendt                  Expires September 14, 2017               [Page 5]


Internet-Draft                    idreg                       March 2017


   Request:
     PUT /idreg/createidentity

     Pass the following object (JSON) in the body.

     ---------------------------------------------------------------
     Property      Type         Description
     ---------------------------------------------------------------
     user_type     string       (MAND) Type representing user/sub
     user_type_id  string       (MAND) ID associated with user
                                Example: accountID of user
     user_info     stringified  (OPT) User specific metadata
                   JSON
     service_id    string       (MAND) Service type identifier
                                Example: "pstn", "voip". "volte"
     public_id     string       (MAND) User associated service
                                identifier. Example: telephone
                                number

     An Authorization Header MUST be included with a JWT including
     timestamp, x5u, and signature that will be associated with this
     transaction.

   Response:
     ---------------------------------------------------------------
     Code  Status
     ---------------------------------------------------------------
     201   user profile created, associate public id,
           returns new routing ID
     200   user profile and public id association already exists
           returns the same routing ID (Idempotent)
     204   service identifier not found
     400   input errors
     401   unauthorized API access - Signature validation failed
     5xx   errors related to DB access and other system anomalies

     For HTTP/1.1 200 OK and HTTP/1.1 201 Created responses:
     ----------------------------------------------------------------
     Property     Type         Description
     ----------------------------------------------------------------
     user_id      string       Globally Unique ID (UUID) for user.
     routing_id   string       routing ID









Wendt                  Expires September 14, 2017               [Page 6]


Internet-Draft                    idreg                       March 2017


4.2.2.  Example

   As part of the allocation, the service provider will be required to
   provide following information:

   o  publicID: telephone number in e.164 format (e.g., +12155551212).

   o  serviceID: "voip" by default, other services potentially in
      future.

   o  routingID: SIP URI with telephone number + domain representing
      service provider of record (e.g.,
      sip:+12155551212@voip.example.com).

   o  timestamp: a timestamp retrieved from a common NTP server
      representing time of allocation, used for validating which service
      provider allocated first in race condition scenarios, and just for
      logging and historical reference in general.

   o  x5u: used for validation of signature

   o  signature: using a provider level [RFC5280] based private key/
      certificate, the provider MUST sign the information above to
      validate the change to the registry.

4.3.  Update Entry/Port

   If a provider needs to update information related to an allocated
   entry, such as adding a publicID, modify routingID, etc.  or if there
   is a port where a new service provider will overwrite the entry with
   new information, the API should be the same.

   There is a GET operation to read the current entry information, if
   the provider needs this information, (e.g., read/modify/write).
   There also is a PUT operation that will write the updated entry
   information.  This will require a new timestamp and signature to
   validate the security of the operation and logging/historical
   purposes.

4.3.1.  API definition

   The PUT /idreg/createidentity API can be used for updates to entries
   as it's an idempotent API.  For porting of telephone numbers either
   createidentity or a combination of the delete described in the next
   section and createidentity can be used.






Wendt                  Expires September 14, 2017               [Page 7]


Internet-Draft                    idreg                       March 2017


4.4.  Removal/de-allocation

   If a provider wants to remove an entry for the case where a customer
   removes his service and no longer wants to own or associate a public
   identity, a DELETE operation will be provided that will delete the
   entry, and for the case of a telephone number, will put the telephone
   number back in the pool of unallocated numbers.

4.4.1.  API definition

   Request:
     DELETE /idreg/identitymapping/serviceid/:id/publicid/:id

     Pass the following object (JSON) in the body.

     ---------------------------------------------------------------
     Property      Type         Description
     ---------------------------------------------------------------
     service_id    string       (MAND) Service type identifier
                                Example: "pstn", "voip". "volte"
     public_id     string       (MAND) User associated service
                                identifier. Example: telephone
                                number

     An Authorization Header MUST be included with a JWT including
     timestamp, x5u, and signature that will be associated with this
     transaction.

   Response:
     ---------------------------------------------------------------
     Code  Status
     ---------------------------------------------------------------
     200   public ID association deleted
     204   record with service_id and public_id in request URI not
           found
     400   input errors
     401   unauthorized API access - Signature validation failed
     5xx   errors related to DB access and other system anomalies

     For HTTP/1.1 200 OK and HTTP/1.1 201 Created responses:
     ----------------------------------------------------------------
     Property     Type         Description
     ----------------------------------------------------------------
     user_id      string       Globally Unique ID (UUID) for user.
     routing_id   string       routing ID






Wendt                  Expires September 14, 2017               [Page 8]


Internet-Draft                    idreg                       March 2017


5.  Security Considerations

   TBD

6.  Acknowledgements

   Thanks to Harsha Bellur for collaboration on developing this model
   and it's implementation.

7.  References

7.1.  Normative References

   [I-D.wendt-modern-drip]
              Bellur, H. and C. Wendt, "Distributed Registry Protocol",
              draft-wendt-modern-drip-01 (work in progress), July 2016.

7.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
              March 2011, <http://www.rfc-editor.org/info/rfc6120>.

Author's Address










Wendt                  Expires September 14, 2017               [Page 9]


Internet-Draft                    idreg                       March 2017


   Chris Wendt
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   USA

   Email: chris-ietf@chriswendt.net












































Wendt                  Expires September 14, 2017              [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/