idnits 2.17.1 draft-bertola-dns-openid-pidi-architecture-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-sanz-openid-dns-discovery-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Bertola 3 Internet-Draft Open-Xchange 4 Intended status: Informational M. Sanz 5 Expires: September 6, 2018 DENIC eG 6 March 5, 2018 8 An Architecture for a Public Identity Infrastructure Based on DNS and 9 OpenID Connect 10 draft-bertola-dns-openid-pidi-architecture-01 12 Abstract 14 The following document describes an architecture for an open, global, 15 federated Public Identity Infrastructure (PIDI), based on the Domain 16 Name System (DNS) and on the OpenID Connect framework built over the 17 OAuth protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 6, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Notation and Conventions . . . . . . . . . . . . 3 55 3. Key features . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Technical design and motivations . . . . . . . . . . . . . . 4 57 4.1. Advantages and shortcomings of OpenID Connect . . . . . . 5 58 4.2. Motivations for the use of the Domain Name System . . . . 5 59 4.3. Separation of roles . . . . . . . . . . . . . . . . . . . 6 60 5. Elements of the architecture . . . . . . . . . . . . . . . . 6 61 5.1. User . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.2. Online identity . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. Identifier . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.4. Identity handle . . . . . . . . . . . . . . . . . . . . . 8 65 5.5. Claim . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.6. Identity authority . . . . . . . . . . . . . . . . . . . 8 67 5.7. Identity agent . . . . . . . . . . . . . . . . . . . . . 10 68 5.8. Relying party . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Interaction flows . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1. Identifier creation flow . . . . . . . . . . . . . . . . 12 71 6.2. Authentication flow . . . . . . . . . . . . . . . . . . . 13 72 6.3. Identifier deletion flow . . . . . . . . . . . . . . . . 14 73 6.4. Change of Identity Agent flow . . . . . . . . . . . . . . 15 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 How to deal with online identities is one of the great unsolved 83 problems of today's Internet: each Internet user has to authenticate 84 for hundreds of different online services, all of which require some 85 personal information that he or she has to provide and maintain 86 separately; and this leads to severe usability and security issues. 88 This document describes an architecture for a Public Identity 89 Infrastructure (PIDI), an identity management framework, building on 90 existing protocols and on new extensions, that can provide the three 91 basic functions of online identity management - authentication, 92 authorization, and management of personal information - and do so in 93 an open, global and federated manner, creating a single interoperable 94 personal identity space that can be shared by the entire Internet, 95 while at the same time preventing any centralized control of all 96 online identities and empowering users rather than identity 97 providers. 99 2. Requirements Notation and Conventions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 Throughout this document, values are quoted to indicate that they are 106 to be taken literally. When using these values in protocol messages, 107 the quotes MUST NOT be used as part of the value. 109 3. Key features 111 In the PIDI architecture described in this document, people and other 112 entities identify themselves in their online activities by using a 113 DNS-style label, located inside an existing and valid domain name, as 114 an identifier. Such identifier allows users to log into any Internet 115 service using a single account associated to their identifier. 117 Identifiers are jointly managed by two complementary entities, acting 118 together as the identity provider; users are able to choose the 119 managers of their identifier among any number of compatible 120 providers, or to host one themselves. 122 Users can employ their identifier to log into any website or online 123 service supporting this architecture, even without prior 124 registration; on first access to that specific service, the service 125 can request access to the user's personal information as entered by 126 him or her into the personal profile. 128 If the user consents to this access, the requested information will 129 be made available to the service, which can thus automatically 130 present the appropriate messages and legal information and then 131 create a local account or profile for the user, associated to the 132 identifier. Thus, "registering" for an online service is not 133 necessary any more; users just self-identify themselves whenever 134 necessary. 136 As the architecture is federated, like email and other public 137 Internet standards, multiple interoperable providers of identifiers 138 can exist, including personal providers self-hosted by their users; 139 all of them are intrinsically supported by any online service 140 implementing the standard, though services, like in the email 141 environment, may implement local policies that blacklist certain 142 providers or identifiers, or treat them differently. Users can pick 143 any provider and, if they control the domain name to which the 144 identifier belongs, can move their identifier to a different provider 145 whenever they want, simply by changing a record in the domain name's 146 zone. 148 By performing authentication in a single place, users are freed from 149 the need to remember, update and protect huge numbers of passwords. 150 Any password change, any security update and any additional 151 authentication mechanism, such as two-factor authentication, can be 152 implemented once and immediately apply to all the logins of the user, 153 thus making it easier to upkeep security. The system can work with 154 any type of authentication mechanism, even without passwords. 156 The focus of this architecture is to authorize and authenticate users 157 in the online space only, i.e. to ensure that the user of a given 158 identifier is always the same that initially acquired that identifier 159 at registration; the architecture does not address the issue of how 160 to actually verify his or her true identity in the real world. 161 Accordingly, there is no requirement for an actual real-life 162 authentication of the users, and their identity and personal 163 information are entirely self-declared; users may also have multiple 164 identities (e.g. a personal one, a business one etc.), as an 165 additional protection to their privacy. 167 At the same time, nothing prevents specific implementations or 168 specific identity providers to support third-party validation of the 169 user's personal information, thus also providing proof of the user's 170 real world identity, which may also be required by specific services 171 to accept the identifier. However, interaction with online-offline 172 authentication systems and providers, such as governmental e-ID 173 documents or certification authorities, is outside of the scope of 174 this document, except for what may be necessary to transfer and store 175 inside this architecture the additional information related to this 176 interaction. 178 4. Technical design and motivations 180 To simplify implementation, the architecture discussed in this 181 document builds over an existing and widely adopted identity 182 management framework: OpenID Connect [OpenID.Core]. However, that 183 framework fails short of several of the requirements and objectives 184 set forth in the previous section. 186 The proposal thus uses a pillar of the Internet, the Domain Name 187 System [RFC1034], and a few purpose-developed specifications such as 188 [I-D.sanz-openid-dns-discovery], to complete OpenID Connect and reach 189 the desired objectives. 191 4.1. Advantages and shortcomings of OpenID Connect 193 OpenID Connect [OpenID.Core] is an identity management framework that 194 has been recently gaining widespread adoption; it gets nearer than 195 others to meeting the requirements. Building on the OAuth 2.0 196 [RFC6749] authorization framework, OpenID Connect provides 197 authentication, authorization, and basic management of personal 198 information; it is currently already being used by many big Internet 199 access and content providers to offer authentication to third-party 200 services, and many different implementations, both commercial and 201 free, are readily available. 203 However, OpenID Connect, in its current status, is aimed at the 204 creation of individual and non-interoperable sets of identities, 205 entirely controlled by a single identity provider. While this design 206 suits a company willing to provide single sign-on for all its 207 websites, or an online service willing to let other services 208 authenticate users against the credentials it provides, there is no 209 easy way for multiple providers to offer identities in the same 210 interoperable set, or for online services to support identities by 211 multiple providers without explicitly implementing separate support 212 for each and every provider; and there is no way to create a single, 213 public, global identity set that can be used by the entire Internet 214 without having to rely on a single and centralized identity provider. 215 Also, once users adopt an identifier run by a specific provider, 216 there is no way for them to move it transparently to another 217 provider. 219 In the end, the centralization of all three functions and of the 220 ownership of the user's identifier in a single entity that cannot be 221 easily picked and changed by the user creates significant risks for 222 privacy and security, and prevents competition and choice among 223 multiple identity providers. While users should be able to 224 centralize these functions in a single entity that they really trust, 225 they should also have the options of owning the identifier directly, 226 of distributing these functions among more than one entity and of 227 changing these entities as easily as possible. 229 4.2. Motivations for the use of the Domain Name System 231 To create a single identity framework for the entire Internet, a 232 single namespace and a lookup service for the identities are 233 necessary; and to prevent control by a single entity, they need to be 234 implemented in a decentralized and federated manner that must also 235 provide the necessary security features. 237 The Internet already relies for its basic functioning on a single 238 namespace and on a lookup service: the Domain Name System [RFC1034]. 240 The ubiquitousness of the DNS, the familiarity of Internet users with 241 DNS-style hierarchical strings, and the increasing adoption of DNSSEC 242 [RFC4033], make the DNS the proper container for a public, secure, 243 decentralized and hierarchical identity naming and lookup service. 245 By using DNS strings as identifiers for human identities, with the 246 addition of a simple mapping mechanism such as that described in 247 [I-D.sanz-openid-dns-discovery], it is immediate for anyone to know 248 where and how to look up information about an identifier, without 249 knowing any other piece of data - not even the identity provider that 250 is managing it. 252 Moreover, other provider discovery mechanisms that rely on different 253 protocols, such as HTTP, still require the client to query the DNS to 254 find the IP address of the server that it has to connect to; by 255 storing the necessary information in the DNS, the initial DNS query 256 is all that is needed to perform the discovery, avoiding the need to 257 implement additional protocols and procedures in the client and in 258 the server. 260 Locating identity identifiers in the DNS has the additional advantage 261 that users, rather than identity providers, can easily become the 262 sole owners of their identifier by acquiring a personal domain name; 263 the controller of that zone - the user - can point the identifier 264 towards a different provider just by changing a record in the zone, 265 even without the current provider's consent or action, much reducing 266 the opportunities for user lock-in by the identity provider. 268 4.3. Separation of roles 270 While the current OpenID Connect implementations concentrate 271 authentication, authorization and personal information management all 272 in a single entity, a separation of roles is introduced to increase 273 the decentralization and security of the system, mimicking the roles 274 existing in the Domain Name System industry. Two different entities 275 - an "identity authority" and an "identity agent" - co-manage each 276 online identity, fulfilling different functions, with the user being 277 free to choose and change each of them, and even to run directly one 278 or both of these roles. 280 5. Elements of the architecture 282 5.1. User 284 A user of the PIDI architecture is an entity of any kind - a physical 285 person, a juridical person, a host, an application, or anything else 286 - that needs to authenticate itself to gain access to online services 287 and applications, and to provide and distribute over the Internet, in 288 a controlled manner, information about itself. 290 5.2. Online identity 292 An online identity is a collection of personal information associated 293 to an identifier that represents it. 295 No assumption is made on whether distinct online identities belong to 296 distinct physical persons, or even whether they belong to human 297 beings at all. Users may own any number of online identities; they 298 should not be required to disclose the correlation between their 299 different online identities. 301 The personal information included in an online identity is entirely 302 self-asserted by the controlling user; in the absence of appropriate 303 additional mechanisms outside the purview of this document, 304 assumptions should not be made on whether such information is "true" 305 or "false" for any definition of these terms. The only assumption 306 that can be safely made about the personal information included in an 307 online identity is that the controlling user is stating that 308 information about himself, herself or itself. 310 5.3. Identifier 312 A PIDI identifier is a string, unique on a global Internet scale at 313 any given time, that represents a distinct online identity in the 314 PIDI architecture. 316 PIDI identifiers MUST follow any syntax which is acceptable to the 317 mapping mechanism described in [I-D.sanz-openid-dns-discovery]. 318 Specifically, an identifier MUST be one of the following: 320 o A fully qualified DNS name following the conventions set forth in 321 section 2.3.1 of [RFC1035]. 323 o A syntactically valid internationalized DNS name (IDN) as per 324 [RFC5890]. 326 o An e-mail address following the syntax described in section 3.4.1 327 of [RFC5322]. 329 o A syntactically valid internationalized e-mail address within the 330 framework of [RFC6530]. 332 In all these cases, no assumption is made on whether these strings 333 actually correspond to existing network objects such as a host or a 334 mailbox; they could not correspond to anything but the online 335 identity that they represent. However, when applying the mapping 336 mechanism to an identifier, the resulting string MUST belong to an 337 existing and working domain name, and MUST point to an existing DNS 338 record of the appropriate type and syntax as specified in 339 [I-D.sanz-openid-dns-discovery]. 341 As the ownership of domain names may change over time, the identity 342 pointed at by a PIDI identifier may change as well. Relying parties 343 should not assume that the same PIDI identifier, over time, will 344 always refer to the same identity. 346 5.4. Identity handle 348 An identity handle is a string of alphanumeric characters which 349 uniquely and permanently identifies a specific online identity. 351 Identity handles are generated and maintained by identity 352 authorities, which provide them to each relying party during the 353 authentication flow. The autority can assign one or more handles to 354 the same online identity; however, the identity authority MUST always 355 provide the same identity handle to the same relying party for the 356 same online identity. 358 Identity authorities MUST NOT reuse an identity handle for a 359 different online identity, even after the identity that was 360 originally associated to that handle has been permanently deleted. 362 5.5. Claim 364 A claim is a piece of information associated to the online identity 365 that is represented by an identifier. 367 Claims are made by a standard claim name, to which a predefined claim 368 type is associated, and by a claim value that contains the actual 369 information. To ensure interoperability, claim names and types are 370 publicly standardized. 372 Claims MUST follow the specification and format described in 373 [OpenID.Core]; however, further claim names and types may be defined 374 in additional specifications. 376 5.6. Identity authority 378 An identity authority is an entity responsible for the authentication 379 and authorization functions of the PIDI identity management 380 framework. 382 More specifically, the identity authority MUST perform the following 383 activities: 385 o Allow identity agents, on behalf of their users, to create, update 386 and cancel identifiers, verifying the proper set up of the 387 required DNS records in the identifier's domain name zone, 388 including an appropriate proof that the user has write access to 389 that zone. 391 o Allow the user to set the password or the other credentials that 392 will be used for authentication, and store them securely. 394 o Authenticate the user whenever necessary; to this purpose, the 395 authority should either ask the user to provide credentials and 396 verify them, or rely on the secure storage of the results of a 397 previous authentication. 399 o Whenever the user tries to log into an online service for the 400 first time, or whenever the service requests access to additional 401 claims, show the user the list of claims that the service would 402 like to access, and ask the user for specific and separate consent 403 on the sharing of each claim; then, authorize the service to 404 access the consented claims at the appropriate identity agent. 406 o Allow the user to review and change the consent that was given for 407 access to claims, for each claim and relying party. 409 To perform these activities, the identity authority MUST act as the 410 OpenID Provider defined in [OpenID.Core]; it MUST also allow third 411 parties to retrieve its OpenID Configuration according to the 412 specification in section 4 of [OpenID.Discovery]. 414 Moreover, the identity authority MUST allow relying parties to 415 perform dynamic client registration as defined in 416 [OpenID.Registration], and it MUST NOT require any Initial Access 417 Token or other out-of-band mechanisms, though an authority may apply 418 policies to prevent some clients from registering if these clients 419 can be presumed to be abusive or malicious. The identity authority 420 MUST use the distributed claims mechanism described in section 5.6.2 421 of [OpenID.Core] to direct a service requesting access to claims to 422 the identity agent managing the personal information associated with 423 the identifier. 425 The identity authority, unless also acting as identity agent, should 426 not have access to any claim associated to the online identity, 427 except the identifier, the authentication credentials and any 428 personal information necessary to verify them, or that the user has 429 voluntarily shared with the identity authority to allow it to provide 430 its services. 432 After each login attempt by the user, the identity authority SHOULD 433 communicate to the identity agent that such attempt has happened and 434 what was its outcome. Details for such communication will be 435 specified separately. 437 5.7. Identity agent 439 An identity agent is an entity responsible for the personal 440 information management function of the PIDI identity management 441 framework, as well as for the management of the relationship with 442 final users. 444 More specifically, the identity agent MUST perform the following 445 activities: 447 o Allow users to acquire, move and cancel their identifiers, 448 performing the necessary technical operations. 450 o Allow users to enter, update and delete the value for any claim 451 supported by the architecture and by the agent. 453 o Provide to any relying party that shows a valid authorization, 454 received by the appropriate identity authority, access to the 455 claims that the user has consented to share with that relying 456 party. 458 The identity agent should also perform the following activities: 460 o Allow users to verify which claims have been shared with each 461 relying party. 463 o Allow users to retrieve a list and history of their logins, unless 464 such information has not been made available to the identity 465 agent. 467 To perform these activities, the identity agent MUST act as a 468 provider of distributed claims as defined in [OpenID.Core], running 469 an appropriate UserInfo Endpoint; it MUST allow access to such 470 endpoint to any relying party that has been successfully authorized 471 to do so by the identity authority. The identity agent MUST also 472 allow third parties to retrieve its OpenID Configuration according to 473 the specification in section 4 of [OpenID.Discovery]. It SHOULD also 474 provide to identity authorities and relying parties an endpoint to 475 communicate user logins. 477 The identity agent, unless also acting as identity authority, should 478 not have access to the user's password; it also should not have 479 access to other credentials used for the authentication process, 480 unless they are claims that can be legitimately used for other 481 purposes (e.g. a mobile phone number). The identity agent should use 482 the PIDI identifier to grant access to its PIDI services, relying on 483 the identity authority for authentication. 485 5.8. Relying party 487 A relying party is any online service, website or application willing 488 to accept PIDI identifiers to recognize and authenticate its users. 490 A relying party can accept PIDI identifiers natively, using them as 491 the sole identification method for its accounts, or can use PIDI 492 identifiers as a pointer towards an internal username in its own 493 accounting system. In both cases, the relying party should allow 494 users to register and authenticate with any valid PIDI identifier, 495 though the relying party may apply policies to reject or discriminate 496 against specific identity agents or identity authorities that are 497 credibly presumed to be abusive or malicious. Moreover, a relying 498 party may apply its own policies and requirements to determine which 499 users should be disallowed from using its services, even if they show 500 up with a valid PIDI identifier. 502 More specifically, the relying party MUST perform the following 503 activities: 505 o Allow users to enter a PIDI identifier in its login and 506 registration forms or procedures. 508 o Perform the mapping described in [I-D.sanz-openid-dns-discovery] 509 and then an OpenID Connect authentication flow, to authenticate 510 the user, to gain authorization to access the user's claims, to 511 retrieve such claims as authorized, and optionally to use them to 512 create or update a local account for the user. 514 To perform these activities, the relying party MUST act as the 515 Relying Party defined in [OpenID.Core]; it MUST also perform a 516 dynamic client registration as defined in [OpenID.Registration], 517 every time it encounters an identity authority never seen before. To 518 do so, the relying party MUST be able to retrieve the OpenID 519 configuration of the identity authority and of the identity agent, 520 according to the specification in section 4 of [OpenID.Discovery]. 522 The relying party, unless also acting as identity authority, should 523 not have access to the user's password; it also should not have 524 access to other credentials used for the authentication process, 525 unless they are claims that the user has authorized the relying party 526 to access. Moreover, the relying party should never have access to 527 any user claims different from those that the user has authorized the 528 relying party to access, and it should honor any request by the user 529 to update or delete the claims that he or she already provided. 531 After each login attempt by the user, the relying party SHOULD 532 communicate to the identity agent that such attempt has happened and 533 what was its outcome. Details for such communication will be 534 specified separately. 536 6. Interaction flows 538 The following sections provide a high-level description of the 539 sequence of steps that has to be followed jointly by the various 540 actors to perform some basic actions. The sequence of steps is meant 541 to be normative, but the detailed technical specification of each 542 step can be found in the standards referenced in the previous 543 section, or in further standards that will be specified separately. 545 6.1. Identifier creation flow 547 To create a valid identifier, the actors have to follow this 548 procedure: 550 1. The user approaches an identity agent and requests the provision 551 of an identifier, agreeing with the agent on the identity 552 authority that will manage it. 554 2. If necessary, the identity agent registers and/or sets up the 555 domain name in which the identifier will be created. 557 3. The identity agent or the user, depending on who operates the 558 domain name, sets up the appropriate DNS record for the mapping 559 of the identifier. 561 4. The identity agent requests the creation of the identifier at the 562 agreed identity authority. 564 5. The identity authority verifies that the DNS record has been 565 successfully set up and that the user, either directly or through 566 the identity agent, has write access to the domain name zone of 567 the identifier. 569 6. If verifications are successful, the identity authority creates 570 the identifier, in inactive state, and communicates success to 571 the agent. 573 7. The agent communicates success to the user and redirects the user 574 to the identity authority to set up the authentication 575 credentials. 577 8. The user approaches the identity authority and sets up the 578 authentication credentials. 580 9. Upon successful setup of the authentication credentials, the 581 identity authority activates the identifier and communicates 582 success to the user. 584 After the conclusion of this procedure, the identifier is ready for 585 use for authentication. 587 6.2. Authentication flow 589 To authenticate and log the user into a relying party, the actors 590 have to follow this procedure: 592 1. The relying party asks the user to provide the identifier. 594 2. The user provides an identifier of choice, corresponding to the 595 online identity that the user chooses to use for this login, to 596 the relying party. 598 3. The relying party performs a DNS lookup to identify the identity 599 authority and the identity agent that manage the identifier. 601 4. If the relying party has never performed a login towards that 602 specific identity authority, or if for any reason (e.g. 603 expiration) it does not possess any valid credentials towards 604 that identity authority, the relying party performs OpenID 605 Connect Discovery section 4 and then OpenID Dynamic Client 606 Registration towards the identity authority, to acquire valid 607 OpenID Connect client credentials; the acquired credentials may 608 be stored for future use. 610 5. The relying party and the user perform an OpenID Connect 611 authentication using the Authorization Code Flow, at the end of 612 which the relying party receives an Identity Token and, if claims 613 need to be accessed, an Access Token. The Identity Token will 614 also include the identity handle associated to the identifier; 615 the relying party should then use the identity handle, rather 616 than the identifier, as the key to refer to the online identity 617 in its own local datasets. Optionally, at the end of this step, 618 the identity authority communicates to the identity agent that a 619 login has been made by the user towards that relying party. 620 During the Authorization Code Flow, the identity authority must 621 ask the user for separate and specific consent to share each 622 claim that has been requested by the relying party, and store 623 this consent for future reference. 625 6. If the relying party has been granted access to any claims, but 626 has never performed a connection towards that specific identity 627 agent, the relying party performs OpenID Connect Discovery 628 section 4 towards the identity agent. 630 7. If the relying party has been granted access to any claims, it 631 performs a connection to the UserInfo Endpoint of the identity 632 authority, that will use the Distributed Claims mechanism to 633 redirect the relying party to the identity agent; the relying 634 party then connects to the UserInfo Endpoint of the identity 635 agent and retrieves the claims. 637 8. Optionally, if appropriate, the relying party creates a local 638 account for the user and stores the identity handle and the 639 values of the claims into it. If necessary, this step can be 640 subject to further direct interaction between the user and the 641 relying party, for example to ask the user to accept the relying 642 party's terms and conditions. 644 After the conclusion of this procedure, the user has logged into the 645 relying party and provided it with the appropriate personal 646 information; if necessary, the relying party has created a new local 647 account for the user. 649 6.3. Identifier deletion flow 651 To delete an existing identifier the actors have to follow this 652 procedure: 654 1. The user requests the deletion of the identifier at the identity 655 agent (the user might also request deletion of the domain name in 656 which the identifier resides, but this is out of scope). The 657 identity agent stops delivering any claims about the user on its 658 UserInfo Endpoint. 660 2. The identity agent or the user, depending on who operates the 661 domain name, deletes the DNS record for the mapping of the 662 identifier. 664 3. The identify agent notifies the identity authority about the 665 deletion request, so that deletion of stored credentials is 666 triggered. 668 4. The identity authority verifies that the source of the deletion 669 request, either directly or through the identity agent, has write 670 access to the domain name zone of the identifier. 672 5. The identity authority communicates success to the agent. 674 6. The agent communicates success to the user and redirects the user 675 to the identity authority to confirm deletion. 677 7. The user approaches the identity authority and deletes all 678 authentication credentials, together with all potentially stored 679 consents for sharing claims. From this point on, the identity 680 authority should reject any authentication requests for this user 681 by any relying parties. 683 It must be noted that, although from step 2 on (or more exactly, 684 after expiration of the pertinent DNS information) the identifier 685 should have been rendered useless because no discovery information is 686 publicly available anymore, this does not suffice for a complete 687 identifier deletion: Relying parties might have cached discovery 688 information (s. Section 6.2 step 3), which would leave the 689 identifier operating in authentication flows for an uncertain amount 690 of time. 692 It must also be noted that any local accounts that might have been 693 created at relying parties during past usage of the now deleted 694 identifier (and that might be directly associated to its identity 695 handle) are left intact after this flow. [NOTE: Discuss risks in 696 security considerations, specially wrt identifier reregistration]. 698 6.4. Change of Identity Agent flow 700 The user might want to move the identifier from one identity agent 701 (losing agent) to another (gaining agent). It is a requirement that 702 the functionality of the identifier (specially for authentication 703 flows) is not affected during this change. A change in the identity 704 authority during this workflow is not foreseen. Actors have to 705 follow this procedure: 707 1. The user approaches the gaining agent and requests the provision 708 of the identifier. 710 2. The gaining agent sets up the domain name in which the identifier 711 will be created. 713 3. The gaining agent or the user, depending on who operates the 714 domain name, sets up a new DNS record for the mapping of the 715 identifier. 717 4. The gaining agent requests the sponsorship of the domain name, in 718 which the identifier resides, at the domain name registry. This 719 might happen via EPP transfer command (s. [RFC5731]); details 720 are out of scope in this document. 722 5. If the transfer of sponsorship is successful, the new DNS mapping 723 will become authoritative and relying parties will start 724 discovering the gaining agent when requesting user claims. 726 Additionally, for considerations on DNS operator change procedures 727 that maintain consistency and validation under DNSSEC please refer to 728 [draft-koch-dnsop-dnssec-operator-change-06]. 730 7. Security Considerations 732 tbd 734 8. Privacy Considerations 736 About rogue Identity Authority monitoring 738 About Whois information on the identifiers 740 9. IANA Considerations 742 There is no IANA action required for this document. 744 10. Normative References 746 [I-D.sanz-openid-dns-discovery] 747 Bertola, V. and M. Sanz, "OpenID Connect DNS-based 748 Discovery", draft-sanz-openid-dns-discovery-00 (work in 749 progress), October 2017. 751 [OpenID.Core] 752 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 753 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 754 . 756 [OpenID.Discovery] 757 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 758 Connect Discovery 1.0", November 2014, 759 . 762 [OpenID.Registration] 763 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 764 Dynamic Client Registration 1.0", November 2014, 765 . 768 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 769 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 770 . 772 [RFC1035] Mockapetris, P., "Domain names - implementation and 773 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 774 November 1987, . 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 782 Rose, "DNS Security Introduction and Requirements", 783 RFC 4033, DOI 10.17487/RFC4033, March 2005, 784 . 786 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 787 DOI 10.17487/RFC5322, October 2008, 788 . 790 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 791 Domain Name Mapping", STD 69, RFC 5731, 792 DOI 10.17487/RFC5731, August 2009, 793 . 795 [RFC5890] Klensin, J., "Internationalized Domain Names for 796 Applications (IDNA): Definitions and Document Framework", 797 RFC 5890, DOI 10.17487/RFC5890, August 2010, 798 . 800 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 801 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 802 February 2012, . 804 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 805 RFC 6749, DOI 10.17487/RFC6749, October 2012, 806 . 808 Authors' Addresses 810 Vittorio Bertola 811 Open-Xchange 812 Via Treviso 12 813 Torino 10144 814 Italy 816 Email: vittorio.bertola@open-xchange.com 817 URI: https://www.open-xchange.com 819 Marcos Sanz 820 DENIC eG 821 Kaiserstrasse 75 - 77 822 Frankfurt am Main 60329 823 Germany 825 Email: sanz@denic.de 826 URI: https://www.denic.de