idnits 2.17.1 draft-bertola-dns-openid-pidi-architecture-00.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 (October 27, 2017) is 2366 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: April 30, 2018 DENIC eG 6 October 27, 2017 8 An Architecture for a Public Identity Infrastructure Based on DNS and 9 OpenID Connect 10 draft-bertola-dns-openid-pidi-architecture-00 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 April 30, 2018. 36 Copyright Notice 38 Copyright (c) 2017 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 1. Introduction 53 How to deal with online identities is one of the great unsolved 54 problems of today's Internet: each Internet user has to authenticate 55 for hundreds of different online services, all of which require some 56 personal information that he or she has to provide and maintain 57 separately; and this leads to severe usability and security issues. 59 This document describes an architecture for a Public Identity 60 Infrastructure (PIDI), an identity management framework, building on 61 existing protocols and on new extensions, that can provide the three 62 basic functions of online identity management - authentication, 63 authorization, and management of personal information - and do so in 64 an open, global and federated manner, creating a single interoperable 65 personal identity space that can be shared by the entire Internet, 66 while at the same time preventing any centralized control of all 67 online identities and empowering users rather than identity 68 providers. 70 2. Requirements Notation and Conventions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 Throughout this document, values are quoted to indicate that they are 77 to be taken literally. When using these values in protocol messages, 78 the quotes MUST NOT be used as part of the value. 80 3. Key features 82 In the PIDI architecture described in this document, people and other 83 entities identify themselves in their online activities by using a 84 DNS-style label, located inside an existing and valid domain name, as 85 an identifier. Such identifier allows users to log into any Internet 86 service using a single account associated to their identifier. 88 Identifiers are jointly managed by two complementary entities, acting 89 together as the identity provider; users are able to choose the 90 managers of their identifier among any number of compatible 91 providers, or to host one themselves. 93 Users can employ their identifier to log into any website or online 94 service supporting this architecture, even without prior 95 registration; on first access to that specific service, the service 96 can request access to the user's personal information as entered by 97 him or her into the personal profile. 99 If the user consents to this access, the requested information will 100 be made available to the service, which can thus automatically 101 present the appropriate messages and legal information and then 102 create a local account or profile for the user, associated to the 103 identifier. Thus, "registering" for an online service is not 104 necessary any more; users just self-identify themselves whenever 105 necessary. 107 As the architecture is federated, like email and other public 108 Internet standards, multiple interoperable providers of identifiers 109 can exist, including personal providers self-hosted by their users; 110 all of them are intrinsically supported by any online service 111 implementing the standard, though services, like in the email 112 environment, may implement local policies that blacklist certain 113 providers or identifiers, or treat them differently. Users can pick 114 any provider and, if they control the domain name to which the 115 identifier belongs, can move their identifier to a different provider 116 whenever they want, simply by changing a record in the domain name's 117 zone. 119 By performing authentication in a single place, users are freed from 120 the need to remember, update and protect huge numbers of passwords. 121 Any password change, any security update and any additional 122 authentication mechanism, such as two-factor authentication, can be 123 implemented once and immediately apply to all the logins of the user, 124 thus making it easier to upkeep security. The system can work with 125 any type of authentication mechanism, even without passwords. 127 The focus of this architecture is to authorize and authenticate users 128 in the online space only, i.e. to ensure that the user of a given 129 identifier is always the same that initially acquired that identifier 130 at registration; the architecture does not address the issue of how 131 to actually verify his or her true identity in the real world. 132 Accordingly, there is no requirement for an actual real-life 133 authentication of the users, and their identity and personal 134 information are entirely self-declared; users may also have multiple 135 identities (e.g. a personal one, a business one etc.), as an 136 additional protection to their privacy. 138 At the same time, nothing prevents specific implementations or 139 specific identity providers to support third-party validation of the 140 user's personal information, thus also providing proof of the user's 141 real world identity, which may also be required by specific services 142 to accept the identifier. However, interaction with online-offline 143 authentication systems and providers, such as governmental e-ID 144 documents or certification authorities, is outside of the scope of 145 this document, except for what may be necessary to transfer and store 146 inside this architecture the additional information related to this 147 interaction. 149 4. Technical design and motivations 151 To simplify implementation, the architecture discussed in this 152 document builds over an existing and widely adopted identity 153 management framework: OpenID Connect [OpenID.Core]. However, that 154 framework fails short of several of the requirements and objectives 155 set forth in the previous section. 157 The proposal thus uses a pillar of the Internet, the Domain Name 158 System [RFC1034], and a few purpose-developed specifications such as 159 [I-D.sanz-openid-dns-discovery], to complete OpenID Connect and reach 160 the desired objectives. 162 4.1. Advantages and shortcomings of OpenID Connect 164 OpenID Connect [OpenID.Core] is an identity management framework that 165 has been recently gaining widespread adoption; it gets nearer than 166 others to meeting the requirements. Building on the OAuth 2.0 167 [RFC6749] authorization framework, OpenID Connect provides 168 authentication, authorization, and basic management of personal 169 information; it is currently already being used by many big Internet 170 access and content providers to offer authentication to third-party 171 services, and many different implementations, both commercial and 172 free, are readily available. 174 However, OpenID Connect, in its current status, is aimed at the 175 creation of individual and non-interoperable sets of identities, 176 entirely controlled by a single identity provider. While this design 177 suits a company willing to provide single sign-on for all its 178 websites, or an online service willing to let other services 179 authenticate users against the credentials it provides, there is no 180 easy way for multiple providers to offer identities in the same 181 interoperable set, or for online services to support identities by 182 multiple providers without explicitly implementing separate support 183 for each and every provider; and there is no way to create a single, 184 public, global identity set that can be used by the entire Internet 185 without having to rely on a single and centralized identity provider. 186 Also, once users adopt an identifier run by a specific provider, 187 there is no way for them to move it transparently to another 188 provider. 190 In the end, the centralization of all three functions and of the 191 ownership of the user's identifier in a single entity that cannot be 192 easily picked and changed by the user creates significant risks for 193 privacy and security, and prevents competition and choice among 194 multiple identity providers. While users should be able to 195 centralize these functions in a single entity that they really trust, 196 they should also have the options of owning the identifier directly, 197 of distributing these functions among more than one entity and of 198 changing these entities as easily as possible. 200 4.2. Motivations for the use of the Domain Name System 202 To create a single identity framework for the entire Internet, a 203 single namespace and a lookup service for the identities are 204 necessary; and to prevent control by a single entity, they need to be 205 implemented in a decentralized and federated manner that must also 206 provide the necessary security features. 208 The Internet already relies for its basic functioning on a single 209 namespace and on a lookup service: the Domain Name System [RFC1034]. 210 The ubiquitousness of the DNS, the familiarity of Internet users with 211 DNS-style hierarchical strings, and the increasing adoption of DNSSEC 212 [RFC4033], make the DNS the proper container for a public, secure, 213 decentralized and hierarchical identity naming and lookup service. 215 By using DNS strings as identifiers for human identities, with the 216 addition of a simple mapping mechanism such as that described in 217 [I-D.sanz-openid-dns-discovery], it is immediate for anyone to know 218 where and how to look up information about an identifier, without 219 knowing any other piece of data - not even the identity provider that 220 is managing it. 222 Locating identity identifiers in the DNS has the additional advantage 223 that users, rather than identity providers, can easily become the 224 sole owners of their identifier by acquiring a personal domain name; 225 the controller of that zone - the user - can point the identifier 226 towards a different provider just by changing a record in the zone, 227 even without the current provider's consent or action, much reducing 228 the opportunities for user lock-in by the identity provider. 230 4.3. Separation of roles 232 While the current OpenID Connect implementations concentrate 233 authentication, authorization and personal information management all 234 in a single entity, a separation of roles is introduced to increase 235 the decentralization and security of the system, mimicking the roles 236 existing in the Domain Name System industry. Two different entities 237 - an "identity authority" and an "identity agent" - co-manage each 238 online identity, fulfilling different functions, with the user being 239 free to choose and change each of them, and even to run directly one 240 or both of these roles. 242 5. Elements of the architecture 244 5.1. User 246 A user of the PIDI architecture is an entity of any kind - a physical 247 person, a juridical person, a host, an application, or anything else 248 - that needs to authenticate itself to gain access to online services 249 and applications, and to provide and distribute over the Internet, in 250 a controlled manner, information about itself. 252 5.2. Online identity 254 An online identity is a collection of personal information associated 255 to an identifier that represents it. 257 No assumption is made on whether distinct online identities belong to 258 distinct physical persons, or even whether they belong to human 259 beings at all. Users may own any number of online identities; they 260 should not be required to disclose the correlation between their 261 different online identities. 263 The personal information included in an online identity is entirely 264 self-asserted by the controlling user; in the absence of appropriate 265 additional mechanisms outside the purview of this document, 266 assumptions should not be made on whether such information is "true" 267 or "false" for any definition of these terms. The only assumption 268 that can be safely made about the personal information included in an 269 online identity is that the controlling user is stating that 270 information about himself, herself or itself. 272 5.3. Identifier 274 A PIDI identifier is a string, unique on a global Internet scale, 275 that represents a distinct online identity in the PIDI architecture. 277 PIDI identifiers MUST follow any syntax which is acceptable to the 278 mapping mechanism described in [I-D.sanz-openid-dns-discovery]. 279 Specifically, an identifier MUST be one of the following: 281 o A fully qualified DNS name following the conventions set forth in 282 section 2.3.1 of [RFC1035]. 284 o A syntactically valid internationalized DNS name (IDN) as per 285 [RFC5890]. 287 o An e-mail address following the syntax described in section 3.4.1 288 of [RFC5322]. 290 o A syntactically valid internationalized e-mail address within the 291 framework of [RFC6530]. 293 In all these cases, no assumption is made on whether these strings 294 actually correspond to existing network objects such as a host or a 295 mailbox; they could not correspond to anything but the online 296 identity that they represent. However, when applying the mapping 297 mechanism to an identifier, the resulting string MUST belong to an 298 existing and working domain name, and MUST point to an existing DNS 299 record of the appropriate type and syntax as specified in 300 [I-D.sanz-openid-dns-discovery]. 302 5.4. Claim 304 A claim is a piece of information associated to the online identity 305 that is represented by an identifier. 307 Claims are made by a standard claim name, to which a predefined claim 308 type is associated, and by a claim value that contains the actual 309 information. To ensure interoperability, claim names and types are 310 publicly standardized. 312 Claims MUST follow the specification and format described in 313 [OpenID.Core]; however, further claim names and types may be defined 314 in additional specifications. 316 5.5. Identity authority 318 An identity authority is an entity responsible for the authentication 319 and authorization functions of the PIDI identity management 320 framework. 322 More specifically, the identity authority MUST perform the following 323 activities: 325 o Allow identity agents, on behalf of their users, to create, update 326 and cancel identifiers, verifying the proper set up of the 327 required DNS records in the identifier's domain name zone, 328 including an appropriate proof that the user has write access to 329 that zone. 331 o Allow the user to set the password or the other credentials that 332 will be used for authentication, and store them securely. 334 o Authenticate the user whenever necessary; to this purpose, the 335 authority should either ask the user to provide credentials and 336 verify them, or rely on the secure storage of the results of a 337 previous authentication. 339 o Whenever the user tries to log into an online service for the 340 first time, or whenever the service requests access to additional 341 claims, show the user the list of claims that the service would 342 like to access, and ask the user for specific and separate consent 343 on the sharing of each claim; then, authorize the service to 344 access the consented claims at the appropriate identity agent. 346 o Allow the user to review and change the consent that was given for 347 access to claims, for each claim and relying party. 349 To perform these activities, the identity authority MUST act as the 350 OpenID Provider defined in [OpenID.Core]; it MUST also allow third 351 parties to retrieve its OpenID Configuration according to the 352 specification in section 4 of [OpenID.Discovery]. 354 Moreover, the identity authority MUST allow relying parties to 355 perform dynamic client registration as defined in 356 [OpenID.Registration], and it MUST NOT require any Initial Access 357 Token or other out-of-band mechanisms, though an authority may apply 358 policies to prevent some clients from registering if these clients 359 can be presumed to be abusive or malicious. The identity authority 360 MUST use the distributed claims mechanism described in section 5.6.2 361 of [OpenID.Core] to direct a service requesting access to claims to 362 the identity agent managing the personal information associated with 363 the identifier. 365 The identity authority, unless also acting as identity agent, should 366 not have access to any claim associated to the online identity, 367 except the identifier, the authentication credentials and any 368 personal information necessary to verify them, or that the user has 369 voluntarily shared with the identity authority to allow it to provide 370 its services. 372 After each login attempt by the user, the identity authority SHOULD 373 communicate to the identity agent that such attempt has happened and 374 what was its outcome. Details for such communication will be 375 specified separately. 377 5.6. Identity agent 379 An identity agent is an entity responsible for the personal 380 information management function of the PIDI identity management 381 framework, as well as for the management of the relationship with 382 final users. 384 More specifically, the identity agent MUST perform the following 385 activities: 387 o Allow users to acquire, move and cancel their identifiers, 388 performing the necessary technical operations. 390 o Allow users to enter, update and delete the value for any claim 391 supported by the architecture and by the agent. 393 o Provide to any relying party that shows a valid authorization, 394 received by the appropriate identity authority, access to the 395 claims that the user has consented to share with that relying 396 party. 398 The identity agent should also perform the following activities: 400 o Allow users to verify which claims have been shared with each 401 relying party. 403 o Allow users to retrieve a list and history of their logins, unless 404 such information has not been made available to the identity 405 agent. 407 To perform these activities, the identity agent MUST act as a 408 provider of distributed claims as defined in [OpenID.Core], running 409 an appropriate UserInfo Endpoint; it MUST allow access to such 410 endpoint to any relying party that has been successfully authorized 411 to do so by the identity authority. The identity agent MUST also 412 allow third parties to retrieve its OpenID Configuration according to 413 the specification in section 4 of [OpenID.Discovery]. It SHOULD also 414 provide to identity authorities and relying parties an endpoint to 415 communicate user logins. 417 The identity agent, unless also acting as identity authority, should 418 not have access to the user's password; it also should not have 419 access to other credentials used for the authentication process, 420 unless they are claims that can be legitimately used for other 421 purposes (e.g. a mobile phone number). The identity agent should use 422 the PIDI identifier to grant access to its PIDI services, relying on 423 the identity authority for authentication. 425 5.7. Relying party 427 A relying party is any online service, website or application willing 428 to accept PIDI identifiers to recognize and authenticate its users. 430 A relying party can accept PIDI identifiers natively, using them as 431 the sole identification method for its accounts, or can use PIDI 432 identifiers as a pointer towards an internal username in its own 433 accounting system. In both cases, the relying party should allow 434 users to register and authenticate with any valid PIDI identifier, 435 though the relying party may apply policies to reject or discriminate 436 against specific identity agents or identity authorities that are 437 credibly presumed to be abusive or malicious. Moreover, a relying 438 party may apply its own policies and requirements to determine which 439 users should be disallowed from using its services, even if they show 440 up with a valid PIDI identifier. 442 More specifically, the relying party MUST perform the following 443 activities: 445 o Allow users to enter a PIDI identifier in its login and 446 registration forms or procedures. 448 o Perform the mapping described in [I-D.sanz-openid-dns-discovery] 449 and then an OpenID Connect authentication flow, to authenticate 450 the user, to gain authorization to access the user's claims, to 451 retrieve such claims as authorized, and optionally to use them to 452 create or update a local account for the user. 454 To perform these activities, the relying party MUST act as the 455 Relying Party defined in [OpenID.Core]; it MUST also perform a 456 dynamic client registration as defined in [OpenID.Registration], 457 every time it encounters an identity authority never seen before. To 458 do so, the relying party MUST be able to retrieve the OpenID 459 configuration of the identity authority and of the identity agent, 460 according to the specification in section 4 of [OpenID.Discovery]. 462 The relying party, unless also acting as identity authority, should 463 not have access to the user's password; it also should not have 464 access to other credentials used for the authentication process, 465 unless they are claims that the user has authorized the relying party 466 to access. Moreover, the relying party should never have access to 467 any user claims different from those that the user has authorized the 468 relying party to access, and it should honor any request by the user 469 to update or delete the claims that he or she already provided. 471 After each login attempt by the user, the relying party SHOULD 472 communicate to the identity agent that such attempt has happened and 473 what was its outcome. Details for such communication will be 474 specified separately. 476 6. Interaction flows 478 The following sections provide a high-level description of the 479 sequence of steps that has to be followed jointly by the various 480 actors to perform some basic actions. The sequence of steps is meant 481 to be normative, but the detailed technical specification of each 482 step can be found in the standards referenced in the previous 483 section, or in further standards that will be specified separately. 485 6.1. Identifier creation flow 487 To create a valid identifier, the actors have to follow this 488 procedure: 490 1. The user approaches an identity agent and requests the provision 491 of an identifier, agreeing with the agent on the identity 492 authority that will manage it. 494 2. If necessary, the identity agent registers and/or sets up the 495 domain name in which the identifier will be created. 497 3. The identity agent or the user, depending on who operates the 498 domain name, sets up the appropriate DNS record for the mapping 499 of the identifier. 501 4. The identity agent requests the creation of the identifier at the 502 agreed identity authority. 504 5. The identity authority verifies that the DNS record has been 505 successfully set up and that the user, either directly or through 506 the identity agent, has write access to the domain name zone of 507 the identifier. 509 6. If verifications are successful, the identity authority creates 510 the identifier, in inactive state, and communicates success to 511 the agent. 513 7. The agent communicates success to the user and redirects the user 514 to the identity authority to set up the authentication 515 credentials. 517 8. The user approaches the identity authority and sets up the 518 authentication credentials. 520 9. Upon successful setup of the authentication credentials, the 521 identity authority activates the identifier and communicates 522 success to the user. 524 After the conclusion of this procedure, the identifier is ready for 525 use for authentication. 527 6.2. Authentication flow 529 To authenticate and log the user into a relying party, the actors 530 have to follow this procedure: 532 1. The relying party asks the user to provide the identifier. 534 2. The user provides an identifier of choice, corresponding to the 535 online identity that the user chooses to use for this login, to 536 the relying party. 538 3. The relying party performs a DNS lookup to identify the identity 539 authority and the identity agent that manage the identifier. 541 4. If the relying party has never performed a login towards that 542 specific identity authority, or if for any reason (e.g. 543 expiration) it does not possess any valid credentials towards 544 that identity authority, the relying party performs OpenID 545 Connect Discovery section 4 and then OpenID Dynamic Client 546 Registration towards the identity authority, to acquire valid 547 OpenID Connect client credentials; the acquired credentials may 548 be stored for future use. 550 5. The relying party and the user perform an OpenID Connect 551 authentication using the Authorization Code Flow, at the end of 552 which the relying party receives an Identity Token and, if claims 553 need to be accessed, an Access Token. Optionally, at the end of 554 this step, the identity authority communicates to the identity 555 agent that a login has been made by the user towards that relying 556 party. During the Authorization Code Flow, the identity 557 authority must ask the user for separate and specific consent to 558 share each claim that has been requested by the relying party, 559 and store this consent for future reference. 561 6. If the relying party has been granted access to any claims, but 562 has never performed a connection towards that specific identity 563 agent, the relying party performs OpenID Connect Discovery 564 section 4 towards the identity agent. 566 7. If the relying party has been granted access to any claims, it 567 performs a connection to the UserInfo Endpoint of the identity 568 authority, that will use the Distributed Claims mechanism to 569 redirect the relying party to the identity agent; the relying 570 party then connects to the UserInfo Endpoint of the identity 571 agent and retrieves the claims. 573 8. Optionally, if appropriate, the relying party creates a local 574 account for the user and stores the identifier and the values of 575 the claims into it. If necessary, this step can be subject to 576 further direct interaction between the user and the relying 577 party, for example to ask the user to accept the relying party's 578 terms and conditions. 580 After the conclusion of this procedure, the user has logged into the 581 relying party and provided it with the appropriate personal 582 information; if necessary, the relying party has created a new local 583 account for the user. 585 7. Security Considerations 587 tbd 589 8. IANA Considerations 591 tbd 593 9. Normative References 595 [I-D.sanz-openid-dns-discovery] 596 Bertola, V. and M. Sanz, "OpenID Connect DNS-based 597 Discovery", draft-sanz-openid-dns-discovery-00 (work in 598 progress), October 2017. 600 [OpenID.Core] 601 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 602 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 603 . 605 [OpenID.Discovery] 606 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 607 Connect Discovery 1.0", November 2014, 608 . 611 [OpenID.Registration] 612 Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect 613 Dynamic Client Registration 1.0", November 2014, 614 . 617 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 618 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 619 . 621 [RFC1035] Mockapetris, P., "Domain names - implementation and 622 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 623 November 1987, . 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, 627 DOI 10.17487/RFC2119, March 1997, 628 . 630 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 631 Rose, "DNS Security Introduction and Requirements", 632 RFC 4033, DOI 10.17487/RFC4033, March 2005, 633 . 635 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 636 DOI 10.17487/RFC5322, October 2008, 637 . 639 [RFC5890] Klensin, J., "Internationalized Domain Names for 640 Applications (IDNA): Definitions and Document Framework", 641 RFC 5890, DOI 10.17487/RFC5890, August 2010, 642 . 644 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 645 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 646 February 2012, . 648 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 649 RFC 6749, DOI 10.17487/RFC6749, October 2012, 650 . 652 Authors' Addresses 654 Vittorio Bertola 655 Open-Xchange 656 Via Treviso 12 657 Torino 10144 658 Italy 660 Email: vittorio.bertola@open-xchange.com 661 URI: https://www.open-xchange.com 662 Marcos Sanz 663 DENIC eG 664 Kaiserstrasse 75 - 77 665 Frankfurt am Main 60329 666 Germany 668 Email: sanz@denic.de 669 URI: https://www.denic.de