| Network Working Group | V. Bertola |
| Internet-Draft | Open-Xchange |
| Intended status: Informational | M. Sanz |
| Expires: September 6, 2018 | DENIC eG |
| March 5, 2018 |
An Architecture for a Public Identity Infrastructure Based on DNS and OpenID Connect
draft-bertola-dns-openid-pidi-architecture-01
The following document describes an architecture for an open, global, federated Public Identity Infrastructure (PIDI), based on the Domain Name System (DNS) and on the OpenID Connect framework built over the OAuth protocol.
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 https://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 6, 2018.
Copyright (c) 2018 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 (https://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 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.
How to deal with online identities is one of the great unsolved problems of today's Internet: each Internet user has to authenticate for hundreds of different online services, all of which require some personal information that he or she has to provide and maintain separately; and this leads to severe usability and security issues.
This document describes an architecture for a Public Identity Infrastructure (PIDI), an identity management framework, building on existing protocols and on new extensions, that can provide the three basic functions of online identity management - authentication, authorization, and management of personal information - and do so in an open, global and federated manner, creating a single interoperable personal identity space that can be shared by the entire Internet, while at the same time preventing any centralized control of all online identities and empowering users rather than identity providers.
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].
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value.
In the PIDI architecture described in this document, people and other entities identify themselves in their online activities by using a DNS-style label, located inside an existing and valid domain name, as an identifier. Such identifier allows users to log into any Internet service using a single account associated to their identifier.
Identifiers are jointly managed by two complementary entities, acting together as the identity provider; users are able to choose the managers of their identifier among any number of compatible providers, or to host one themselves.
Users can employ their identifier to log into any website or online service supporting this architecture, even without prior registration; on first access to that specific service, the service can request access to the user’s personal information as entered by him or her into the personal profile.
If the user consents to this access, the requested information will be made available to the service, which can thus automatically present the appropriate messages and legal information and then create a local account or profile for the user, associated to the identifier. Thus, "registering" for an online service is not necessary any more; users just self-identify themselves whenever necessary.
As the architecture is federated, like email and other public Internet standards, multiple interoperable providers of identifiers can exist, including personal providers self-hosted by their users; all of them are intrinsically supported by any online service implementing the standard, though services, like in the email environment, may implement local policies that blacklist certain providers or identifiers, or treat them differently. Users can pick any provider and, if they control the domain name to which the identifier belongs, can move their identifier to a different provider whenever they want, simply by changing a record in the domain name’s zone.
By performing authentication in a single place, users are freed from the need to remember, update and protect huge numbers of passwords. Any password change, any security update and any additional authentication mechanism, such as two-factor authentication, can be implemented once and immediately apply to all the logins of the user, thus making it easier to upkeep security. The system can work with any type of authentication mechanism, even without passwords.
The focus of this architecture is to authorize and authenticate users in the online space only, i.e. to ensure that the user of a given identifier is always the same that initially acquired that identifier at registration; the architecture does not address the issue of how to actually verify his or her true identity in the real world. Accordingly, there is no requirement for an actual real-life authentication of the users, and their identity and personal information are entirely self-declared; users may also have multiple identities (e.g. a personal one, a business one etc.), as an additional protection to their privacy.
At the same time, nothing prevents specific implementations or specific identity providers to support third-party validation of the user’s personal information, thus also providing proof of the user’s real world identity, which may also be required by specific services to accept the identifier. However, interaction with online-offline authentication systems and providers, such as governmental e-ID documents or certification authorities, is outside of the scope of this document, except for what may be necessary to transfer and store inside this architecture the additional information related to this interaction.
To simplify implementation, the architecture discussed in this document builds over an existing and widely adopted identity management framework: OpenID Connect [OpenID.Core]. However, that framework fails short of several of the requirements and objectives set forth in the previous section.
The proposal thus uses a pillar of the Internet, the Domain Name System [RFC1034], and a few purpose-developed specifications such as [I-D.sanz-openid-dns-discovery], to complete OpenID Connect and reach the desired objectives.
OpenID Connect [OpenID.Core] is an identity management framework that has been recently gaining widespread adoption; it gets nearer than others to meeting the requirements. Building on the OAuth 2.0 [RFC6749] authorization framework, OpenID Connect provides authentication, authorization, and basic management of personal information; it is currently already being used by many big Internet access and content providers to offer authentication to third-party services, and many different implementations, both commercial and free, are readily available.
However, OpenID Connect, in its current status, is aimed at the creation of individual and non-interoperable sets of identities, entirely controlled by a single identity provider. While this design suits a company willing to provide single sign-on for all its websites, or an online service willing to let other services authenticate users against the credentials it provides, there is no easy way for multiple providers to offer identities in the same interoperable set, or for online services to support identities by multiple providers without explicitly implementing separate support for each and every provider; and there is no way to create a single, public, global identity set that can be used by the entire Internet without having to rely on a single and centralized identity provider. Also, once users adopt an identifier run by a specific provider, there is no way for them to move it transparently to another provider.
In the end, the centralization of all three functions and of the ownership of the user's identifier in a single entity that cannot be easily picked and changed by the user creates significant risks for privacy and security, and prevents competition and choice among multiple identity providers. While users should be able to centralize these functions in a single entity that they really trust, they should also have the options of owning the identifier directly, of distributing these functions among more than one entity and of changing these entities as easily as possible.
To create a single identity framework for the entire Internet, a single namespace and a lookup service for the identities are necessary; and to prevent control by a single entity, they need to be implemented in a decentralized and federated manner that must also provide the necessary security features.
The Internet already relies for its basic functioning on a single namespace and on a lookup service: the Domain Name System [RFC1034]. The ubiquitousness of the DNS, the familiarity of Internet users with DNS-style hierarchical strings, and the increasing adoption of DNSSEC [RFC4033], make the DNS the proper container for a public, secure, decentralized and hierarchical identity naming and lookup service.
By using DNS strings as identifiers for human identities, with the addition of a simple mapping mechanism such as that described in [I-D.sanz-openid-dns-discovery], it is immediate for anyone to know where and how to look up information about an identifier, without knowing any other piece of data - not even the identity provider that is managing it.
Moreover, other provider discovery mechanisms that rely on different protocols, such as HTTP, still require the client to query the DNS to find the IP address of the server that it has to connect to; by storing the necessary information in the DNS, the initial DNS query is all that is needed to perform the discovery, avoiding the need to implement additional protocols and procedures in the client and in the server.
Locating identity identifiers in the DNS has the additional advantage that users, rather than identity providers, can easily become the sole owners of their identifier by acquiring a personal domain name; the controller of that zone - the user - can point the identifier towards a different provider just by changing a record in the zone, even without the current provider's consent or action, much reducing the opportunities for user lock-in by the identity provider.
While the current OpenID Connect implementations concentrate authentication, authorization and personal information management all in a single entity, a separation of roles is introduced to increase the decentralization and security of the system, mimicking the roles existing in the Domain Name System industry. Two different entities - an "identity authority" and an "identity agent" - co-manage each online identity, fulfilling different functions, with the user being free to choose and change each of them, and even to run directly one or both of these roles.
A user of the PIDI architecture is an entity of any kind - a physical person, a juridical person, a host, an application, or anything else - that needs to authenticate itself to gain access to online services and applications, and to provide and distribute over the Internet, in a controlled manner, information about itself.
An online identity is a collection of personal information associated to an identifier that represents it.
No assumption is made on whether distinct online identities belong to distinct physical persons, or even whether they belong to human beings at all. Users may own any number of online identities; they should not be required to disclose the correlation between their different online identities.
The personal information included in an online identity is entirely self-asserted by the controlling user; in the absence of appropriate additional mechanisms outside the purview of this document, assumptions should not be made on whether such information is "true" or "false" for any definition of these terms. The only assumption that can be safely made about the personal information included in an online identity is that the controlling user is stating that information about himself, herself or itself.
A PIDI identifier is a string, unique on a global Internet scale at any given time, that represents a distinct online identity in the PIDI architecture.
PIDI identifiers MUST follow any syntax which is acceptable to the mapping mechanism described in [I-D.sanz-openid-dns-discovery]. Specifically, an identifier MUST be one of the following:
In all these cases, no assumption is made on whether these strings actually correspond to existing network objects such as a host or a mailbox; they could not correspond to anything but the online identity that they represent. However, when applying the mapping mechanism to an identifier, the resulting string MUST belong to an existing and working domain name, and MUST point to an existing DNS record of the appropriate type and syntax as specified in [I-D.sanz-openid-dns-discovery].
As the ownership of domain names may change over time, the identity pointed at by a PIDI identifier may change as well. Relying parties should not assume that the same PIDI identifier, over time, will always refer to the same identity.
An identity handle is a string of alphanumeric characters which uniquely and permanently identifies a specific online identity.
Identity handles are generated and maintained by identity authorities, which provide them to each relying party during the authentication flow. The autority can assign one or more handles to the same online identity; however, the identity authority MUST always provide the same identity handle to the same relying party for the same online identity.
Identity authorities MUST NOT reuse an identity handle for a different online identity, even after the identity that was originally associated to that handle has been permanently deleted.
A claim is a piece of information associated to the online identity that is represented by an identifier.
Claims are made by a standard claim name, to which a predefined claim type is associated, and by a claim value that contains the actual information. To ensure interoperability, claim names and types are publicly standardized.
Claims MUST follow the specification and format described in [OpenID.Core]; however, further claim names and types may be defined in additional specifications.
An identity authority is an entity responsible for the authentication and authorization functions of the PIDI identity management framework.
More specifically, the identity authority MUST perform the following activities:
To perform these activities, the identity authority MUST act as the OpenID Provider defined in [OpenID.Core]; it MUST also allow third parties to retrieve its OpenID Configuration according to the specification in section 4 of [OpenID.Discovery].
Moreover, the identity authority MUST allow relying parties to perform dynamic client registration as defined in [OpenID.Registration], and it MUST NOT require any Initial Access Token or other out-of-band mechanisms, though an authority may apply policies to prevent some clients from registering if these clients can be presumed to be abusive or malicious. The identity authority MUST use the distributed claims mechanism described in section 5.6.2 of [OpenID.Core] to direct a service requesting access to claims to the identity agent managing the personal information associated with the identifier.
The identity authority, unless also acting as identity agent, should not have access to any claim associated to the online identity, except the identifier, the authentication credentials and any personal information necessary to verify them, or that the user has voluntarily shared with the identity authority to allow it to provide its services.
After each login attempt by the user, the identity authority SHOULD communicate to the identity agent that such attempt has happened and what was its outcome. Details for such communication will be specified separately.
An identity agent is an entity responsible for the personal information management function of the PIDI identity management framework, as well as for the management of the relationship with final users.
More specifically, the identity agent MUST perform the following activities:
The identity agent should also perform the following activities:
To perform these activities, the identity agent MUST act as a provider of distributed claims as defined in [OpenID.Core], running an appropriate UserInfo Endpoint; it MUST allow access to such endpoint to any relying party that has been successfully authorized to do so by the identity authority. The identity agent MUST also allow third parties to retrieve its OpenID Configuration according to the specification in section 4 of [OpenID.Discovery]. It SHOULD also provide to identity authorities and relying parties an endpoint to communicate user logins.
The identity agent, unless also acting as identity authority, should not have access to the user's password; it also should not have access to other credentials used for the authentication process, unless they are claims that can be legitimately used for other purposes (e.g. a mobile phone number). The identity agent should use the PIDI identifier to grant access to its PIDI services, relying on the identity authority for authentication.
A relying party is any online service, website or application willing to accept PIDI identifiers to recognize and authenticate its users.
A relying party can accept PIDI identifiers natively, using them as the sole identification method for its accounts, or can use PIDI identifiers as a pointer towards an internal username in its own accounting system. In both cases, the relying party should allow users to register and authenticate with any valid PIDI identifier, though the relying party may apply policies to reject or discriminate against specific identity agents or identity authorities that are credibly presumed to be abusive or malicious. Moreover, a relying party may apply its own policies and requirements to determine which users should be disallowed from using its services, even if they show up with a valid PIDI identifier.
More specifically, the relying party MUST perform the following activities:
To perform these activities, the relying party MUST act as the Relying Party defined in [OpenID.Core]; it MUST also perform a dynamic client registration as defined in [OpenID.Registration], every time it encounters an identity authority never seen before. To do so, the relying party MUST be able to retrieve the OpenID configuration of the identity authority and of the identity agent, according to the specification in section 4 of [OpenID.Discovery].
The relying party, unless also acting as identity authority, should not have access to the user's password; it also should not have access to other credentials used for the authentication process, unless they are claims that the user has authorized the relying party to access. Moreover, the relying party should never have access to any user claims different from those that the user has authorized the relying party to access, and it should honor any request by the user to update or delete the claims that he or she already provided.
After each login attempt by the user, the relying party SHOULD communicate to the identity agent that such attempt has happened and what was its outcome. Details for such communication will be specified separately.
The following sections provide a high-level description of the sequence of steps that has to be followed jointly by the various actors to perform some basic actions. The sequence of steps is meant to be normative, but the detailed technical specification of each step can be found in the standards referenced in the previous section, or in further standards that will be specified separately.
To create a valid identifier, the actors have to follow this procedure:
After the conclusion of this procedure, the identifier is ready for use for authentication.
To authenticate and log the user into a relying party, the actors have to follow this procedure:
After the conclusion of this procedure, the user has logged into the relying party and provided it with the appropriate personal information; if necessary, the relying party has created a new local account for the user.
To delete an existing identifier the actors have to follow this procedure:
It must be noted that, although from step 2 on (or more exactly, after expiration of the pertinent DNS information) the identifier should have been rendered useless because no discovery information is publicly available anymore, this does not suffice for a complete identifier deletion: Relying parties might have cached discovery information (s. Section 6.2 step 3), which would leave the identifier operating in authentication flows for an uncertain amount of time.
It must also be noted that any local accounts that might have been created at relying parties during past usage of the now deleted identifier (and that might be directly associated to its identity handle) are left intact after this flow. [NOTE: Discuss risks in security considerations, specially wrt identifier reregistration].
The user might want to move the identifier from one identity agent (losing agent) to another (gaining agent). It is a requirement that the functionality of the identifier (specially for authentication flows) is not affected during this change. A change in the identity authority during this workflow is not foreseen. Actors have to follow this procedure:
Additionally, for considerations on DNS operator change procedures that maintain consistency and validation under DNSSEC please refer to [draft-koch-dnsop-dnssec-operator-change-06].
tbd
About rogue Identity Authority monitoring
About Whois information on the identifiers
There is no IANA action required for this document.