1 Internet Engineering Task Force (IETF)                     S. Hollenbeck   
    2 Request for Comments: 9560                                 Verisign Labs   
    3 Category: Standards Track                                     April 2024   
    4 ISSN: 2070-1721                                                            
    5                                                                            
    6                                                                            
    7    Federated Authentication for the Registration Data Access Protocol      
    8                       (RDAP) Using OpenID Connect                          
    9                                                                            
   10 Abstract                                                                   
   11                                                                            
   12    The Registration Data Access Protocol (RDAP) provides                   
   13    Representational State Transfer (RESTful) web services to retrieve      
   14    registration metadata from domain name and regional internet            
   15    registries.  RDAP allows a server to make access control decisions      
   16    based on client identity, and as such, it includes support for client   
   17    identification features provided by the Hypertext Transfer Protocol     
   18    (HTTP).  Identification methods that require clients to obtain and      
   19    manage credentials from every RDAP server operator present management   
   20    challenges for both clients and servers, whereas a federated            
   21    authentication system would make it easier to operate and use RDAP      
   22    without the need to maintain server-specific client credentials.        
   23    This document describes a federated authentication system for RDAP      
   24    based on OpenID Connect.                                                
   25                                                                            
   26 Status of This Memo                                                        
   27                                                                            
   28    This is an Internet Standards Track document.                           
   29                                                                            
   30    This document is a product of the Internet Engineering Task Force       
   31    (IETF).  It represents the consensus of the IETF community.  It has     
   32    received public review and has been approved for publication by the     
   33    Internet Engineering Steering Group (IESG).  Further information on     
   34    Internet Standards is available in Section 2 of RFC 7841.               
   35                                                                            
   36    Information about the current status of this document, any errata,      
   37    and how to provide feedback on it may be obtained at                    
   38    https://www.rfc-editor.org/info/rfc9560.                                
   39                                                                            
   40 Copyright Notice                                                           
   41                                                                            
   42    Copyright (c) 2024 IETF Trust and the persons identified as the         
   43    document authors.  All rights reserved.                                 
   44                                                                            
   45    This document is subject to BCP 78 and the IETF Trust's Legal           
   46    Provisions Relating to IETF Documents                                   
   47    (https://trustee.ietf.org/license-info) in effect on the date of        
   48    publication of this document.  Please review these documents            
   49    carefully, as they describe your rights and restrictions with respect   
   50    to this document.  Code Components extracted from this document must    
   51    include Revised BSD License text as described in Section 4.e of the     
   52    Trust Legal Provisions and are provided without warranty as described   
   53    in the Revised BSD License.                                             
   54                                                                            
   55 Table of Contents                                                          
   56                                                                            
   57    1.  Introduction                                                        
   58      1.1.  Problem Statement                                               
   59      1.2.  Approach                                                        
   60    2.  Conventions Used in This Document                                   
   61    3.  Federated Authentication for RDAP                                   
   62      3.1.  RDAP and OpenID Connect                                         
   63        3.1.1.  Terminology                                                 
   64        3.1.2.  Client Considerations                                       
   65        3.1.3.  Overview                                                    
   66        3.1.4.  RDAP Authentication and Authorization Steps                 
   67          3.1.4.1.  Provider Discovery                                      
   68          3.1.4.2.  Authentication Request                                  
   69          3.1.4.3.  End User Authorization                                  
   70          3.1.4.4.  Authorization Response and Validation                   
   71          3.1.4.5.  Token Processing                                        
   72          3.1.4.6.  Delivery of User Information                            
   73        3.1.5.  Specialized Claims and Authorization Scope for RDAP         
   74          3.1.5.1.  Stated Purposes                                         
   75          3.1.5.2.  Do Not Track                                            
   76    4.  Common Protocol Features                                            
   77      4.1.  OpenID Connect Configuration                                    
   78      4.2.  RDAP Query Parameters                                           
   79        4.2.1.  RDAP Query Purpose                                          
   80        4.2.2.  RDAP Do Not Track                                           
   81        4.2.3.  Parameter Processing                                        
   82    5.  Protocol Features for Session-Oriented Clients                      
   83      5.1.  Data Structures                                                 
   84        5.1.1.  Session                                                     
   85        5.1.2.  Device Info                                                 
   86      5.2.  Client Login                                                    
   87        5.2.1.  End-User Identifier                                         
   88        5.2.2.  OP Issuer Identifier                                        
   89        5.2.3.  Login Response                                              
   90        5.2.4.  Clients with Limited User Interfaces                        
   91          5.2.4.1.  UI-Constrained Client Login                             
   92          5.2.4.2.  UI-Constrained Client Login Polling                     
   93      5.3.  Session Status                                                  
   94      5.4.  Session Refresh                                                 
   95      5.5.  Client Logout                                                   
   96      5.6.  Request Sequencing                                              
   97    6.  Protocol Features for Token-Oriented Clients                        
   98      6.1.  Client Login                                                    
   99      6.2.  Client Queries                                                  
  100      6.3.  Access Token Validation                                         
  101      6.4.  Token Exchange                                                  
  102    7.  RDAP Query Processing                                               
  103    8.  RDAP Conformance                                                    
  104    9.  IANA Considerations                                                 
  105      9.1.  RDAP Extensions Registry                                        
  106      9.2.  JSON Web Token Claims Registry                                  
  107      9.3.  RDAP Query Purpose Registry                                     
  108    10. Security Considerations                                             
  109      10.1.  Authentication and Access Control                              
  110    11. References                                                          
  111      11.1.  Normative References                                           
  112      11.2.  Informative References                                         
  113    Acknowledgments                                                         
  114    Author's Address                                                        
  115                                                                            
  116 1.  Introduction                                                           
  117                                                                            
  118    The Registration Data Access Protocol (RDAP) provides                   
  119    Representational State Transfer (RESTful) web services to retrieve      
  120    registration metadata from domain name and regional internet            
  121    registries.  RDAP allows a server to make access control decisions      
  122    based on client identity, and as such, it includes support for client   
  123    identification features provided by the Hypertext Transfer Protocol     
  124    (HTTP) [RFC9110].                                                       
  125                                                                            
  126    RDAP is specified in multiple documents, including "HTTP Usage in the   
  127    Registration Data Access Protocol (RDAP)" [RFC7480], "Security          
  128    Services for the Registration Data Access Protocol (RDAP)" [RFC7481],   
  129    "Registration Data Access Protocol (RDAP) Query Format" [RFC9082],      
  130    and "JSON Responses for the Registration Data Access Protocol (RDAP)"   
  131    [RFC9083].  [RFC7481] describes client identification and               
  132    authentication services that can be used with RDAP, but it does not     
  133    specify how any of these services can (or should) be used with RDAP.    
  134                                                                            
  135 1.1.  Problem Statement                                                    
  136                                                                            
  137    The conventional "username and password" authentication method does     
  138    not scale well in the RDAP ecosystem.  Assuming that all domain name    
  139    and address registries will eventually provide RDAP service, it is      
  140    impractical and inefficient for users to secure login credentials       
  141    from the hundreds of different server operators.  Authentication        
  142    methods based on usernames and passwords do not provide information     
  143    that describes the user in sufficient detail (while protecting the      
  144    personal privacy of the user) for server operators to make fine-        
  145    grained access control decisions based on the user's identity.  The     
  146    authentication system used for RDAP needs to address all of these       
  147    needs.                                                                  
  148                                                                            
  149 1.2.  Approach                                                             
  150                                                                            
  151    A basic level of RDAP service can be provided to users who possess an   
  152    identifier issued by a recognized provider who can authenticate and     
  153    validate the user.  For example, the identifiers issued by social       
  154    media services can be used.  Users who require higher levels of         
  155    service (and who are willing to share more information about            
  156    themselves to gain access to that service) can secure identifiers       
  157    from specialized providers who are or will be able to provide more      
  158    detailed information about the user.  Server operators can then make    
  159    access control decisions based on the identification information        
  160    provided by the user.                                                   
  161                                                                            
  162    A federated authentication system in which an RDAP server outsources    
  163    identification and authentication services to a trusted identity        
  164    provider would make it easier to operate and use RDAP by reusing        
  165    existing identifiers to provide a basic level of access.  It can also   
  166    provide the ability to collect additional user identification           
  167    information, and that information can be shared with the RDAP server    
  168    operator with the consent of the user in order to help the server       
  169    operator make access control decisions.  This type of system allows     
  170    an RDAP server to make access control decisions based on the nature     
  171    of a query and the identity, authentication, and authorization          
  172    information that is received from the identity provider.  This          
  173    document describes a federated authentication system for RDAP based     
  174    on OpenID Connect [OIDC] that meets these needs.                        
  175                                                                            
  176 2.  Conventions Used in This Document                                      
  177                                                                            
  178    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  179    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    
  180    "OPTIONAL" in this document are to be interpreted as described in BCP   
  181    14 [RFC2119] [RFC8174] when, and only when, they appear in all          
  182    capitals, as shown here.                                                
  183                                                                            
  184    All of the HTTP requests described in this document that are sent       
  185    from an RDAP client to an RDAP server use the HTTP GET method as        
  186    specified in [RFC9110].                                                 
  187                                                                            
  188    Long lines in examples are wrapped using "The Single Backslash          
  189    Strategy" described in [RFC8792].                                       
  190                                                                            
  191 3.  Federated Authentication for RDAP                                      
  192                                                                            
  193    RDAP itself does not include built-in security services.  Instead,      
  194    RDAP relies on features that are available in other protocol layers     
  195    to provide needed security services including access control,           
  196    authentication, authorization, availability, data confidentiality,      
  197    data integrity, and identification.  A description of each of these     
  198    security services can be found in "Internet Security Glossary,          
  199    Version 2" [RFC4949].  This document focuses on a federated             
  200    authentication system for RDAP that provides services for               
  201    authentication, authorization, and identification, allowing a server    
  202    operator to make access control decisions.  Section 3 of [RFC7481]      
  203    describes general considerations for RDAP access control,               
  204    authentication, and authorization.                                      
  205                                                                            
  206    The conventional client-server authentication model requires clients    
  207    to maintain distinct credentials for every RDAP server.  This           
  208    situation can become unwieldy as the number of RDAP servers             
  209    increases.  Federated authentication mechanisms allow clients to use    
  210    one credential to access multiple RDAP servers and reduce client        
  211    credential management complexity.                                       
  212                                                                            
  213 3.1.  RDAP and OpenID Connect                                              
  214                                                                            
  215    OpenID Connect 1.0 [OIDCC] is a decentralized, Single Sign-On (SSO)     
  216    federated authentication system that allows users to access multiple    
  217    web resources with one identifier instead of having to create           
  218    multiple server-specific identifiers.  Users acquire identifiers from   
  219    OpenID Providers (OPs).  Relying Parties (RPs) are applications (such   
  220    as RDAP) that outsource their user authentication function to an OP.    
  221    OpenID Connect is built on top of the authorization framework           
  222    provided by the OAuth 2.0 protocol [RFC6749].                           
  223                                                                            
  224    The OAuth authorization framework describes a method for users to       
  225    access protected web resources without having to hand out their         
  226    credentials.  Instead, clients are issued access tokens by OPs with     
  227    the permission of the resource owners.  Using OpenID Connect and        
  228    OAuth, multiple RDAP servers can form a federation, and clients can     
  229    access any server in the federation by providing one credential         
  230    registered with any OP in that federation.  The OAuth authorization     
  231    framework is designed for use with HTTP and thus can be used with       
  232    RDAP.                                                                   
  233                                                                            
  234 3.1.1.  Terminology                                                        
  235                                                                            
  236    This document uses the following terminology.                           
  237                                                                            
  238    Terms defined by [RFC7480]:                                             
  239                                                                            
  240    *  client                                                               
  241                                                                            
  242    *  server                                                               
  243                                                                            
  244    Terms defined by [RFC6749]:                                             
  245                                                                            
  246    *  access token                                                         
  247                                                                            
  248    *  authorization code                                                   
  249                                                                            
  250    *  authorization endpoint                                               
  251                                                                            
  252    *  authorization grant                                                  
  253                                                                            
  254    *  client authentication                                                
  255                                                                            
  256    *  client identifier                                                    
  257                                                                            
  258    *  protected resource                                                   
  259                                                                            
  260    *  refresh token                                                        
  261                                                                            
  262    *  resource owner                                                       
  263                                                                            
  264    *  resource server                                                      
  265                                                                            
  266    *  token endpoint                                                       
  267                                                                            
  268    Terms defined by [RFC7519]:                                             
  269                                                                            
  270    *  claim name                                                           
  271                                                                            
  272    *  claim value                                                          
  273                                                                            
  274    *  JSON Web Token (JWT)                                                 
  275                                                                            
  276    Terms defined by [OIDCC]:                                               
  277                                                                            
  278    *  ID Token                                                             
  279                                                                            
  280    *  UserInfo Endpoint                                                    
  281                                                                            
  282    Term defined by [RFC9068]:                                              
  283                                                                            
  284    *  JWT access token                                                     
  285                                                                            
  286    Additional terms from Section 1.2 of the OpenID Connect Core            
  287    specification are incorporated by reference.                            
  288                                                                            
  289    This document uses the terms "remote" and "default" to describe the     
  290    relationship between an RDAP server and the OPs that it interacts       
  291    with.  A "remote" OP is one that is identified by the RDAP client by    
  292    providing either an Issuer Identifier or an end-user identifier in a    
  293    login request.  Whether an Issuer Identifier or end-user identifier     
  294    can be provided in the login request for the purposes of selecting an   
  295    OP can be determined by retrieving the RDAP server's OIDC               
  296    configuration details (see Section 4.1).  A "default" OP is one that    
  297    the RDAP server will use when the RDAP client does not provide an       
  298    Issuer Identifier or an end-user identifier in the login request.       
  299                                                                            
  300    This document uses the term "session" to describe a set of              
  301    interactions between an RDAP client and an RDAP server during a given   
  302    period of time.  For session-oriented clients (see Section 3.1.2),      
  303    the RDAP session is a typical HTTP session starting with a              
  304    farv1_session/login request and ending with either a farv1_session/     
  305    logout request (see Section 5 for a description of both path            
  306    segments) or a timeout.  For token-oriented clients (see Sections       
  307    3.1.2 and 6), the RDAP session corresponds to the lifespan of an        
  308    authorization obtained from an OP and the corresponding access token,   
  309    including any refreshed access tokens.                                  
  310                                                                            
  311 3.1.2.  Client Considerations                                              
  312                                                                            
  313    Clients that delegate OIDC authentication to an RDAP server as part     
  314    of session-oriented interactions and can accept and process HTTP        
  315    cookies [RFC6265] to maintain the session are known as "session-        
  316    oriented" clients.  This type of RDAP client performs the role of a     
  317    user agent [RFC9110].  An RDAP server performs the role of an OpenID    
  318    Connect Core Relying Party (RP).  A web browser used to send queries    
  319    directly to an RDAP server is an example of a session-oriented          
  320    client.  Specifications for this type of client can be found in         
  321    Section 5.                                                              
  322                                                                            
  323    Clients that perform OIDC authentication directly, taking the role of   
  324    an RP in interactions with an OP and sending access tokens [RFC6749]    
  325    to an RDAP server to authorize RDAP queries, are known as "token-       
  326    oriented" clients.  An RDAP server performs resource server [RFC6749]   
  327    functions to verify the tokens received from the client and RP          
  328    functions to retrieve information from the OP as necessary to make      
  329    access control decisions.  A web browser running JavaScript received    
  330    from a web service that sends queries to an RDAP server directly or     
  331    through its back-end web service is an example of a token-oriented      
  332    client.  Specifications for this type of client can be found in         
  333    Section 6.                                                              
  334                                                                            
  335    Clients MAY operate as either session-oriented or token-oriented        
  336    clients, but they MUST do so consistently by not mixing token-          
  337    oriented and session-oriented requests while interacting with an OP.    
  338    Servers SHOULD support both types of client to maximize                 
  339    interoperability but MAY choose to support only one type of client as   
  340    required by local policy or operating conditions.  A server that does   
  341    not support a particular client type will not support the protocol      
  342    features (the data structures, path segments, parameters, and           
  343    interactions) specified for that client type.  Server signaling of      
  344    supported client types is described in Section 4.1.                     
  345                                                                            
  346 3.1.3.  Overview                                                           
  347                                                                            
  348    At a high level, RDAP authentication of a session-oriented client       
  349    using OpenID Connect requires completion of the following steps:        
  350                                                                            
  351    1.   An RDAP client sends an RDAP "help" query to an RDAP server to     
  352         determine the types and capabilities of the OPs that are used by   
  353         the RDAP server.  This information is returned in the              
  354         "rdapConformance" section of the response.  A value of "farv1"     
  355         indicates support for the extension described in this              
  356         specification.  If one or more remote OPs are supported, the       
  357         RDAP client SHOULD evaluate the additional information described   
  358         in Section 4.1 in order to discover the capabilities of the RDAP   
  359         server and optionally obtain the set of supported OPs unless       
  360         that information is available from a trusted out-of-band source    
  361         and has already been processed.                                    
  362                                                                            
  363    2.   An RDAP client sends an RDAP "login" request to an RDAP server     
  364         as described in Section 5.2.                                       
  365                                                                            
  366    3.   The RDAP server prepares an Authentication Request containing      
  367         the desired request parameters.                                    
  368                                                                            
  369    4.   The RDAP server sends an Authentication Request to an OP           
  370         authorization endpoint and redirects the RDAP client to the OP     
  371         using an HTTP redirect.                                            
  372                                                                            
  373    5.   The OP authenticates the end user.                                 
  374                                                                            
  375    6.   The OP obtains end-user consent and authorization.                 
  376                                                                            
  377    7.   The OP sends the RDAP client back to the RDAP server with an       
  378         authorization code using an HTTP redirect.                         
  379                                                                            
  380    8.   The RDAP server requests tokens using the authorization code at    
  381         the OP's token endpoint.                                           
  382                                                                            
  383    9.   The RDAP server receives a response that contains an ID Token      
  384         and access token in the response body.                             
  385                                                                            
  386    10.  The RDAP server validates the tokens as described in [OIDCC] and   
  387         retrieves the claims associated with the end user's identity       
  388         from the OP's UserInfo Endpoint.                                   
  389                                                                            
  390    The steps above can be described in a sequence diagram:                 
  391                                                                            
  392    End          OpenID         RDAP                 RDAP                   
  393    User        Provider       Client               Server                  
  394      |             |             |                    |                    
  395      |             |             |-----Help Query---->|                    
  396      |             |             |                    |                    
  397      |             |             |<---Help Response---|                    
  398      |             |             |                    |                    
  399      |-------Login Request------>|                    |                    
  400      |             |             |                    |                    
  401      |             |             |---Login Request--->|                    
  402      |             |             |                    |                    
  403      |             |<-----Authentication Request------|                    
  404      |             |             |                    |                    
  405      | Credential--|             |                    |                    
  406      |<--Request   |             |                    |                    
  407      |             |             |                    |                    
  408      |--Credential |             |                    |                    
  409      |   Response->|             |                    |                    
  410      |             |             |                    |                    
  411      |             |-----Authentication Response----->|                    
  412      |             |             |                    |                    
  413      |             |<----------Token Request----------|                    
  414      |             |             |                    |                    
  415      |             |-----------Token Response-------->|                    
  416      |             |             |                    |                    
  417      |             |<----------Claim Request----------|                    
  418      |             |             |                    |                    
  419      |             |-----------Claim Response-------->|                    
  420      |             |             |                    |                    
  421      |             |             |<--Login Response---|                    
  422      |             |             |                    |                    
  423      |<------Login Response------|                    |                    
  424      |             |             |                    |                    
  425      |----------RDAP Query------>|                    |                    
  426      |             |             |                    |                    
  427      |             |             |-----RDAP Query---->|                    
  428      |             |             |                    |                    
  429      |             |             |<---RDAP Response---|                    
  430      |             |             |                    |                    
  431      |<------RDAP Response-------|                    |                    
  432                                                                            
  433                                   Figure 1                                 
  434                                                                            
  435    The RDAP server can then make identification, authorization, and        
  436    access control decisions based on end-user identity information and     
  437    local policies.  Note that OpenID Connect describes different process   
  438    flows for other types of clients, such as script-based or command-      
  439    line clients.                                                           
  440                                                                            
  441    RDAP authentication of a token-oriented client using OpenID Connect     
  442    requires completion of the following steps:                             
  443                                                                            
  444    1.   An RDAP client sends an RDAP "help" query to an RDAP server to     
  445         determine the type and capabilities of the OPs that are used by    
  446         the RDAP server.  This information is returned in the              
  447         "rdapConformance" section of the response.  A value of "farv1"     
  448         indicates support for the extension described in this              
  449         specification.  If one or more remote OPs are supported, the       
  450         RDAP client SHOULD evaluate the additional information described   
  451         in Section 4.1 in order to discover the capabilities of the RDAP   
  452         server and optionally obtain the set of supported OPs.  Support    
  453         for token-oriented clients requires a default OP.                  
  454                                                                            
  455    2.   The RDAP client determines the end user's OP and confirms that     
  456         it's supported by the RDAP server.                                 
  457                                                                            
  458    3.   The RDAP client sends an Authentication Request to the OP's        
  459         authorization endpoint.                                            
  460                                                                            
  461    4.   The OP authenticates the end user.                                 
  462                                                                            
  463    5.   The OP obtains end-user consent or authorization.                  
  464                                                                            
  465    6.   The OP returns an authorization code to the RDAP client.           
  466                                                                            
  467    7.   The RDAP client requests tokens using the authorization code at    
  468         the OP's token endpoint.                                           
  469                                                                            
  470    8.   The RDAP client receives a response that contains an ID Token      
  471         and an access token in the response body.                          
  472                                                                            
  473    9.   The RDAP client monitors the token validity period and either      
  474         refreshes the token or requests new tokens as necessary.           
  475                                                                            
  476    10.  The RDAP client sends queries that require user identification,    
  477         authentication, and authorization to an RDAP server that include   
  478         an access token in an HTTP "authorization" header using the        
  479         "bearer" authentication scheme described in [RFC6750].             
  480                                                                            
  481    11.  The RDAP server validates the access token and retrieves the       
  482         claims associated with the end user's identity from the OP's       
  483         UserInfo Endpoint.                                                 
  484                                                                            
  485    12.  The RDAP server determines the end user's authorization level      
  486         and processes the query in accordance with server policies.        
  487                                                                            
  488    The steps above can be described in a sequence diagram:                 
  489                                                                            
  490    End          OpenID         RDAP                 RDAP                   
  491    User        Provider       Client               Server                  
  492      |             |             |                    |                    
  493      |             |             |-----Help Query---->|                    
  494      |             |             |                    |                    
  495      |             |             |<----Help Response--|                    
  496      |             |             |                    |                    
  497      |-------Login Request------>|                    |                    
  498      |             |             |                    |                    
  499      |             |<-Authentication                  |                    
  500      |             |   Request---|                    |                    
  501      |             |             |                    |                    
  502      |<-Credential |             |                    |                    
  503      |   Request---|             |                    |                    
  504      |             |             |                    |                    
  505      |--Credential |             |                    |                    
  506      |   Response->|             |                    |                    
  507      |             |             |                    |                    
  508      |             |--Authentication                  |                    
  509      |             | Response--->|                    |                    
  510      |             |             |                    |                    
  511      |             |<-Token      |                    |                    
  512      |             |  Request----|                    |                    
  513      |             |             |                    |                    
  514      |             |--Token      |                    |                    
  515      |             |  Response-->|                    |                    
  516      |             |             |                    |                    
  517      |<------Login Response------|                    |                    
  518      |             |             |                    |                    
  519      |-----RDAP Query----------->|                    |                    
  520      |             |             |                    |                    
  521      |             |             |----RDAP Query----->|                    
  522      |             |             |                    |                    
  523      |             |<------------Claim                |                    
  524      |             |            Request---------------|                    
  525      |             |             |                    |                    
  526      |             |-------------Claim                |                    
  527      |             |            Response------------->|                    
  528      |             |             |                    |                    
  529      |             |             |<---RDAP Response---|                    
  530      |             |             |                    |                    
  531      |<----RDAP Response---------|                    |                    
  532                                                                            
  533                                   Figure 2                                 
  534                                                                            
  535 3.1.4.  RDAP Authentication and Authorization Steps                        
  536                                                                            
  537    End users MAY present an identifier (an OpenID) issued by an OP to      
  538    use OpenID Connect with RDAP.  If the RDAP server supports a default    
  539    OP or if provider discovery is not supported, the end-user identifier   
  540    MAY be omitted.  An OP SHOULD include support for the claims            
  541    described in Section 3.1.5 to provide additional information needed     
  542    for RDAP end-user authorization; in the absence of these claims,        
  543    clients and servers MAY make authorization and access control           
  544    decisions as appropriate given any other information returned from      
  545    the OP.  OpenID Connect requires RPs to register with OPs to use        
  546    OpenID Connect services for an end user.  The registration process is   
  547    often completed using out-of-band methods, but it is also possible to   
  548    use the automated method described by the OpenID Connect Dynamic        
  549    Client Registration protocol [OIDCR].  The parties involved can use     
  550    any method that is mutually acceptable.                                 
  551                                                                            
  552 3.1.4.1.  Provider Discovery                                               
  553                                                                            
  554    An RDAP server acting as an RP needs to be able to map an end user's    
  555    identifier to an OP.  This can be accomplished using the OPTIONAL       
  556    OpenID Connect Discovery protocol [OIDCD], but that protocol is not     
  557    widely implemented.  Out-of-band methods are also possible and can be   
  558    more dependable.  For example, an RP can support a limited number of    
  559    OPs and maintain internal associations of those identifiers with the    
  560    OPs that issued them.                                                   
  561                                                                            
  562    Alternatively, if mapping an end user's identifier is not possible,     
  563    or not supported by the RDAP server, the RDAP server SHOULD support     
  564    explicit specification of a remote OP by the RDAP client in the form    
  565    of a query parameter as described in Section 5.2.2 unless the remote    
  566    OP has been identified using an out-of-band mechanism.  An RDAP         
  567    server MUST provide information about its capabilities and supported    
  568    OPs in the "help" query response in the "farv1_openidcConfiguration"    
  569    data structure described in Section 4.1.  An RDAP server acting as an   
  570    RP MUST support at least one of these methods of OP discovery.          
  571                                                                            
  572 3.1.4.2.  Authentication Request                                           
  573                                                                            
  574    Once the OP is known, an RP MUST form an Authentication Request and     
  575    send it to the OP as described in Section 3 of [OIDCC].  The            
  576    authentication path followed (authorization, implicit, or hybrid)       
  577    will depend on the Authentication Request response_type set by the      
  578    RP.  The remainder of the processing steps described here assume that   
  579    the authorization code flow is being used by setting                    
  580    "response_type=code" in the Authentication Request.                     
  581                                                                            
  582    The benefits of using the authorization code flow for authenticating    
  583    a human user are described in Section 3.1 of [OIDCC].  The Implicit     
  584    Flow is more commonly used by clients implemented in a web browser      
  585    using a scripting language; it is described in Section 3.2 of           
  586    [OIDCC].  At the time of this writing, the Implicit Flow is             
  587    considered insecure and efforts are being made to deprecate the flow.   
  588    The Hybrid Flow (described in Section 3.3 of [OIDCC]) combines          
  589    elements of the authorization code and Implicit Flows by returning      
  590    some tokens from the authorization endpoint and others from the token   
  591    endpoint.                                                               
  592                                                                            
  593    An Authentication Request can contain several parameters.  REQUIRED     
  594    parameters are specified in Section 3.1.2.1 of [OIDCC].  Apart from     
  595    these parameters, it is RECOMMENDED that the RP include the optional    
  596    "login_hint" parameter in the request, with the value being that of     
  597    the "farv1_id" query parameter of the end user's RDAP "login"           
  598    request, if provided.  Passing the "login_hint" parameter allows a      
  599    client to pre-fill login form information, so logging in can be more    
  600    convenient for users.  Other parameters MAY be included.                
  601                                                                            
  602    The OP receives the Authentication Request and attempts to validate     
  603    it as described in Section 3.1.2.2 of [OIDCC].  If the request is       
  604    valid, the OP attempts to authenticate the end user as described in     
  605    Section 3.1.2.3 of [OIDCC].  The OP returns an error response if the    
  606    request is not valid or if any error is encountered.                    
  607                                                                            
  608 3.1.4.3.  End User Authorization                                           
  609                                                                            
  610    After the end user is authenticated, the OP MUST obtain consent from    
  611    the end user to release authorization information to the RDAP server    
  612    acting as an RP.  This process is described in Section 3.1.2.4 of       
  613    [OIDCC].                                                                
  614                                                                            
  615 3.1.4.4.  Authorization Response and Validation                            
  616                                                                            
  617    After obtaining an authorization result, the OP will send a response    
  618    to the RP that provides the result of the authorization process using   
  619    an authorization code.  The RP MUST validate the response.  This        
  620    process is described in Sections 3.1.2.5 - 3.1.2.7 of [OIDCC].          
  621                                                                            
  622 3.1.4.5.  Token Processing                                                 
  623                                                                            
  624    The RP sends a token request using the authorization grant to a token   
  625    endpoint to obtain a token response containing an access token, ID      
  626    Token, and an OPTIONAL refresh token.  The RP MUST validate the token   
  627    response.  This process is described in Section 3.1.3.5 [OIDCC].        
  628                                                                            
  629 3.1.4.6.  Delivery of User Information                                     
  630                                                                            
  631    The set of claims can be retrieved by sending a request to a UserInfo   
  632    Endpoint using the access token.  The claims are returned in the ID     
  633    Token.  The process of retrieving claims from a UserInfo Endpoint is    
  634    described in Section 5.3 of [OIDCC].                                    
  635                                                                            
  636    OpenID Connect specifies a set of standard claims in Section 5.1 of     
  637    [OIDCC].  Additional claims for RDAP are described in Section 3.1.5.    
  638                                                                            
  639 3.1.5.  Specialized Claims and Authorization Scope for RDAP                
  640                                                                            
  641    OpenID Connect claims are pieces of information used to make            
  642    assertions about an entity.  Section 5 of [OIDCC] describes a set of    
  643    standard claims.  Section 5.1.2 of [OIDCC] notes that additional        
  644    claims MAY be used, and it describes a method to create them.  The      
  645    set of claims that are specific to RDAP are associated with an OAuth    
  646    scope request parameter value (see Section 3.3 of [RFC6749]) of         
  647    "rdap".                                                                 
  648                                                                            
  649 3.1.5.1.  Stated Purposes                                                  
  650                                                                            
  651    Communities of RDAP users and operators may wish to make and validate   
  652    claims about a user's "need to know" when it comes to requesting        
  653    access to a protected resource.  For example, a law enforcement agent   
  654    or a trademark attorney may wish to be able to assert that they have    
  655    a legal right to access a protected resource, and a server operator     
  656    may need to be able to receive and validate that claim.  These needs    
  657    can be met by defining and using an additional                          
  658    "rdap_allowed_purposes" claim.                                          
  659                                                                            
  660    The "rdap_allowed_purposes" claim identifies the purposes for which     
  661    access to a protected resource can be requested by an end user.  Use    
  662    of the "rdap_allowed_purposes" claim is OPTIONAL; processing of this    
  663    claim is subject to server acceptance of the purposes, the trust        
  664    level assigned to this claim by the server, and successful              
  665    authentication of the end user.  Unrecognized purpose values MUST be    
  666    ignored, and the associated query MUST be processed as if the           
  667    unrecognized purpose value was not present at all.  See Section 9.3     
  668    for a description of the IANA considerations associated with this       
  669    claim.                                                                  
  670                                                                            
  671    The "rdap_allowed_purposes" claim is represented as an array of case-   
  672    sensitive StringOrURI values as specified in Section 2 of [RFC7519].    
  673    An example:                                                             
  674                                                                            
  675    "rdap_allowed_purposes": ["domainNameControl","dnsTransparency"]        
  676                                                                            
  677    Purpose values are assigned to an end user's credential by an           
  678    identity provider.  Identity providers MUST ensure that appropriate     
  679    purpose values are only assigned to end user identities that are        
  680    authorized to use them.                                                 
  681                                                                            
  682 3.1.5.2.  Do Not Track                                                     
  683                                                                            
  684    Communities of RDAP users and operators may wish to make and validate   
  685    claims about a user's wish to not have their queries logged, tracked,   
  686    or recorded.  For example, a law enforcement agent may wish to assert   
  687    that their queries are part of a criminal investigation and should      
  688    not be tracked due to a risk of query exposure compromising the         
  689    investigation, and a server operator may need to be able to receive     
  690    and validate that claim.  These needs can be met by defining and        
  691    using an additional "do not track" claim.                               
  692                                                                            
  693    The "do not track" ("rdap_dnt_allowed") claim can be used to identify   
  694    an end user that is authorized to perform queries without the end       
  695    user's association with those queries being logged, tracked, or         
  696    recorded by the server.  Client use of the "rdap_dnt_allowed" claim     
  697    is OPTIONAL.  Server operators MUST NOT log, track, or record any       
  698    association of the query and the end user's identity if the end user    
  699    is successfully identified and authorized, if the "rdap_dnt_allowed"    
  700    claim is present, if the value of the claim is "true", and if           
  701    accepting the claim complies with local regulations regarding logging   
  702    and tracking.                                                           
  703                                                                            
  704    The "rdap_dnt_allowed" value is represented as a JSON boolean           
  705    literal.  An example:                                                   
  706                                                                            
  707    rdap_dnt_allowed: true                                                  
  708                                                                            
  709    No special query tracking processing is required if this claim is not   
  710    present or if the value of the claim is "false".  Use of this claim     
  711    MUST be limited to end users who are granted "do not track"             
  712    privileges in accordance with service policies and regulations.         
  713    Specification of these policies and regulations is beyond the scope     
  714    of this document.                                                       
  715                                                                            
  716 4.  Common Protocol Features                                               
  717                                                                            
  718    As described in Section 3.1.4.1, an RDAP server MUST provide            
  719    information about its capabilities and supported OPs in a "help"        
  720    query response.  This specification describes a new                     
  721    "farv1_openidcConfiguration" data structure that describes the OpenID   
  722    Connect configuration and related extension features supported by the   
  723    RDAP server.  This data structure is returned to all client types.      
  724                                                                            
  725 4.1.  OpenID Connect Configuration                                         
  726                                                                            
  727    The "farv1_openidcConfiguration" data structure is an object with the   
  728    following members:                                                      
  729                                                                            
  730    "sessionClientSupported":  (REQUIRED) a boolean value that describes    
  731       RDAP server support for session-oriented clients (see                
  732       Section 3.1.2).                                                      
  733                                                                            
  734    "tokenClientSupported":  (REQUIRED) a boolean value that describes      
  735       RDAP server support for token-oriented clients (see                  
  736       Section 3.1.2).                                                      
  737                                                                            
  738    "dntSupported":  (REQUIRED) a boolean value that describes RDAP         
  739       server support for the "farv1_dnt" query parameter (see              
  740       Section 4.2.2).                                                      
  741                                                                            
  742    "providerDiscoverySupported":  (OPTIONAL) a boolean value that          
  743       describes RDAP server support for discovery of providers of end-     
  744       user identifiers.  The default value is "true".                      
  745                                                                            
  746    "issuerIdentifierSupported":  (OPTIONAL) a boolean value that           
  747       describes RDAP server support for explicit client specification of   
  748       an Issuer Identifier.  The default value is "true".                  
  749                                                                            
  750    "implicitTokenRefreshSupported":  (OPTIONAL) a boolean value that       
  751       describes RDAP server support for implicit token refresh.  The       
  752       default value is "false".                                            
  753                                                                            
  754    "openidcProviders":  (OPTIONAL) a list of objects with the following    
  755       members that describes the set of OPs that are supported by the      
  756       RDAP server.  This data is RECOMMENDED if the value of               
  757       issuerIdentifierSupported is "true":                                 
  758                                                                            
  759       "iss":  (REQUIRED) a URI value that represents the Issuer            
  760          Identifier of the OP as per the OpenID Connect Core               
  761          specification [OIDCC].                                            
  762                                                                            
  763       "name":  (REQUIRED) a string value representing the human-friendly   
  764          name of the OP.                                                   
  765                                                                            
  766       "default":  (OPTIONAL) a boolean value that describes RDAP server    
  767          support for an OPTIONAL default OP that will be used when a       
  768          client omits the "farv1_id" and "farv1_iss" query parameters      
  769          from a "farv1_session/login" request.  Only one member of this    
  770          set can be identified as the default OP by setting a value of     
  771          "true".  The default value is "false".                            
  772                                                                            
  773       "additionalAuthorizationQueryParams":  (OPTIONAL) an object where    
  774          each member represents an OAuth authorization request parameter   
  775          name-value pair supported by the OP.  The name represents an      
  776          OAuth query parameter, and the value is the query parameter       
  777          value.  A token-oriented RDAP client SHOULD add these query       
  778          parameters and their corresponding values to the Authentication   
  779          Request URL when requesting authorization by a specified OP       
  780          through a proxy OP.                                               
  781                                                                            
  782    An RDAP server MUST set either the "sessionClientSupported" or the      
  783    "tokenClientSupported" value to "true".  Both values MAY be set to      
  784    "true" if an RDAP server supports both types of clients.                
  785                                                                            
  786    The "providerDiscoverySupported" value has a direct impact on the use   
  787    of the "farv1_id" query parameter described in Sections 3.1.4.2 and     
  788    5.2.1.  The value of "providerDiscoverySupported" MUST be "true" for    
  789    an RDAP server to properly accept and process "farv1_id" query          
  790    parameters.  Similarly, the "issuerIdentifierSupported" value has a     
  791    direct impact on the use of the "farv1_iss" query parameter described   
  792    in Section 5.2.2.  The value of "issuerIdentifierSupported" MUST be     
  793    "true" for an RDAP server to properly accept and process "farv1_iss"    
  794    query parameters.                                                       
  795                                                                            
  796    An example of a "farv1_openidcConfiguration" data structure:            
  797                                                                            
  798    "farv1_openidcConfiguration": {                                         
  799      "sessionClientSupported": true,                                       
  800      "tokenClientSupported": true,                                         
  801      "dntSupported": false,                                                
  802      "providerDiscoverySupported": true,                                   
  803      "issuerIdentifierSupported": true,                                    
  804      "openidcProviders":                                                   
  805        [                                                                   
  806          {                                                                 
  807            "iss": "https://idp.example.com",                               
  808            "name": "Example IDP"                                           
  809          },                                                                
  810          {                                                                 
  811            "iss": "https://accounts.example.net",                          
  812            "name": "Login with EXAMPLE",                                   
  813            "additionalAuthorizationQueryParams": {                         
  814              "kc_idp_hint": "examplePublicIDP"                             
  815            }                                                               
  816          },                                                                
  817          {                                                                 
  818            "iss": "https://auth.nic.example/auth/realms/rdap",             
  819            "name": "Default OP for the Example RDAP server",               
  820            "default": true                                                 
  821          }                                                                 
  822        ]                                                                   
  823    }                                                                       
  824                                                                            
  825                                   Figure 3                                 
  826                                                                            
  827 4.2.  RDAP Query Parameters                                                
  828                                                                            
  829    This specification describes two OPTIONAL query parameters for use      
  830    with RDAP queries that request access to information associated with    
  831    protected resources:                                                    
  832                                                                            
  833    "farv1_qp":  A query parameter to identify the purpose of the query.    
  834                                                                            
  835    "farv1_dnt":  A query parameter to request that the server not log or   
  836       otherwise record information about the identity associated with a    
  837       query.                                                               
  838                                                                            
  839    One or both parameters MAY be added to an RDAP request URI using the    
  840    syntax described in Section "application/x-www-form-urlencoded" of      
  841    [HTMLURL].                                                              
  842                                                                            
  843 4.2.1.  RDAP Query Purpose                                                 
  844                                                                            
  845    This query is represented as a "key=value" pair using a key value of    
  846    "farv1_qp" and a value component that contains a single query purpose   
  847    string from the set of allowed purposes associated with the end         
  848    user's identity (see Section 3.1.5.1).  If present, the server SHOULD   
  849    compare the value of the parameter to the "rdap_allowed_purposes"       
  850    claim values associated with the end user's identity and ensure that    
  851    the requested purpose is present in the set of allowed purposes.  The   
  852    RDAP server MAY choose to ignore both the requested purpose and the     
  853    "rdap_allowed_purposes" claim values if they are inconsistent with      
  854    local server policy.  The server MUST return an HTTP 403 (Forbidden)    
  855    response if the requested purpose is not an allowed purpose.  If the    
  856    "farv1_qp" parameter is not present, the server MUST process the        
  857    query and make an access control decision based on any other            
  858    information known to the server about the end user and the              
  859    information they are requesting.  For example, a server MAY treat the   
  860    request as one performed by an unidentified or unauthenticated user     
  861    and return either an error or an appropriate subset of the available    
  862    data.  An example domain query using the "farv1_qp" query parameter:    
  863                                                                            
  864    https://example.com/rdap/domain/example.com?farv1_qp=legalActions       
  865                                                                            
  866                                   Figure 4                                 
  867                                                                            
  868 4.2.2.  RDAP Do Not Track                                                  
  869                                                                            
  870    This query is represented as a "key=value" pair using a key value of    
  871    "farv1_dnt" and a value component that contains a single boolean        
  872    value.  A value of "true" indicates that the end user is requesting     
  873    that their query is not tracked or logged in accordance with server     
  874    policy.  A value of "false" indicates that the end user is accepting    
  875    that their query can be tracked or logged in accordance with server     
  876    policy.  The server MUST return an HTTP 403 (Forbidden) response if     
  877    the server is unable to perform the action requested by this query      
  878    parameter.  An example domain query using the "farv1_dnt" query         
  879    parameter:                                                              
  880                                                                            
  881    https://example.com/rdap/domain/example.com?farv1_dnt=true              
  882                                                                            
  883                                   Figure 5                                 
  884                                                                            
  885 4.2.3.  Parameter Processing                                               
  886                                                                            
  887    Unrecognized query parameters MUST be ignored.  An RDAP server that     
  888    processes an authenticated query MUST determine if the end-user         
  889    identification information is associated with an OP that is             
  890    recognized and supported by the server.  RDAP servers MUST reject       
  891    queries that include identification information that is not             
  892    associated with a supported OP by returning an HTTP 400 (Bad Request)   
  893    response.  An RDAP server that receives a query containing              
  894    identification information associated with a recognized OP MUST         
  895    perform the steps required to authenticate the user with the OP,        
  896    process the query, and return an RDAP response that is appropriate      
  897    for the end user's level of authorization and access.                   
  898                                                                            
  899 5.  Protocol Features for Session-Oriented Clients                         
  900                                                                            
  901    This specification adds the following features to RDAP that are         
  902    commonly used by session-oriented clients:                              
  903                                                                            
  904    1.  Data structures to return information that describes an             
  905        established session and the information needed to establish a       
  906        session for a UI-constrained device.                                
  907                                                                            
  908    2.  A query parameter to request authentication for a specific end-     
  909        user identity.                                                      
  910                                                                            
  911    3.  A query parameter to support authentication for a specific end-     
  912        user identity on a device with a constrained user interface.        
  913                                                                            
  914    4.  A query parameter to identify the purpose of the query.             
  915                                                                            
  916    5.  A query parameter to request that the server not log or otherwise   
  917        record information about the identity associated with a query.      
  918                                                                            
  919    6.  Path segments to start, stop, refresh, and determine the status     
  920        of an authenticated session for a specific end-user identity.       
  921                                                                            
  922 5.1.  Data Structures                                                      
  923                                                                            
  924    This specification describes two new data structures that are used to   
  925    return information to a session-oriented client:                        
  926                                                                            
  927    "farv1_session":  A data structure that contains information that       
  928       describes an established session.                                    
  929                                                                            
  930    "farv1_deviceInfo":  A data structure that contains information that    
  931       describes an active attempt to establish a session on a UI-          
  932       constrained device.                                                  
  933                                                                            
  934 5.1.1.  Session                                                            
  935                                                                            
  936    The "farv1_session" data structure is an object that contains the       
  937    following members:                                                      
  938                                                                            
  939    "userID":  an OPTIONAL string value that represents the end-user        
  940       identifier associated with the session.                              
  941                                                                            
  942    "iss":  an OPTIONAL URI value that represents the issuer of the end-    
  943       user identifier associated with the session.                         
  944                                                                            
  945    "userClaims":  an OPTIONAL object that contains the set of claims       
  946       associated with the end user's identity based on the user            
  947       information provided by the OP as described in Section 3.1.4.6 and   
  948       processed by the RDAP server in the authentication and               
  949       authorization process.  The set of possible values is determined     
  950       by OP policy and RDAP server policy.                                 
  951                                                                            
  952    "sessionInfo":  an OPTIONAL object that contains two members:           
  953                                                                            
  954       "tokenExpiration":  an integer value that represents the number of   
  955          seconds that remain in the lifetime of the access token.          
  956                                                                            
  957       "tokenRefresh":  a boolean value that indicates if the OP supports   
  958          refresh tokens.  As described in [RFC6749], support for refresh   
  959          tokens is OPTIONAL.                                               
  960                                                                            
  961    Note that all of the members of the "farv1_session" data structure      
  962    are OPTIONAL.  See Section 5.2.3 for instructions describing when to    
  963    return the minimum set of members.                                      
  964                                                                            
  965    An example of a "farv1_session" data structure:                         
  966                                                                            
  967      "farv1_session": {                                                    
  968        "userID": "user.idp.example",                                       
  969        "iss": "https://idp.example.com",                                   
  970        "userClaims": {                                                     
  971          "sub": "103892603076825016132",                                   
  972          "name": "User Person",                                            
  973          "given_name": "User",                                             
  974          "family_name": "Person",                                          
  975          "picture": "https://lh3.example.com/a-/AOh14=s96-c",              
  976          "email": "user@example.com",                                      
  977          "email_verified": true,                                           
  978          "locale": "en",                                                   
  979          "rdap_allowed_purposes": [                                        
  980            "domainNameControl",                                            
  981            "personalDataProtection"                                        
  982          ],                                                                
  983          "rdap_dnt_allowed": false                                         
  984        },                                                                  
  985        "sessionInfo": {                                                    
  986          "tokenExpiration": 3599,                                          
  987          "tokenRefresh": true                                              
  988        }                                                                   
  989      }                                                                     
  990                                                                            
  991                                   Figure 6                                 
  992                                                                            
  993 5.1.2.  Device Info                                                        
  994                                                                            
  995    The flow described in Section 3.1.4 requires an end user to interact    
  996    with a server using a user interface that can process HTTP.  This       
  997    will not work well in situations where the client is automated or an    
  998    end user is using a command-line user interface such as curl            
  999    (https://curl.se/) or wget (https://www.gnu.org/software/wget/).        
 1000    This limitation can be addressed using a web browser on a second        
 1001    device.  The information that needs to be entered using the web         
 1002    browser is contained in the "farv1_deviceInfo" data structure, an       
 1003    object that contains members as described in Section 3.2 of             
 1004    [RFC8628].                                                              
 1005                                                                            
 1006    An example of a "farv1_deviceInfo" data structure:                      
 1007                                                                            
 1008      "farv1_deviceInfo": {                                                 
 1009        "device_code": "AH-1ng2ezu",                                        
 1010        "user_code": "NJJQ-GJFC",                                           
 1011        "verification_uri": "https://www.example.com/device",               
 1012        "verification_uri_complete":                                        
 1013           "https://www.example.com/device?user_code=NJJQ-GJFC",            
 1014        "expires_in": 1800,                                                 
 1015        "interval": 5                                                       
 1016      }                                                                     
 1017                                                                            
 1018                                   Figure 7                                 
 1019                                                                            
 1020 5.2.  Client Login                                                         
 1021                                                                            
 1022    Client authentication is requested by sending a "farv1_session/login"   
 1023    request to an RDAP server.  If the RDAP server supports only remote     
 1024    OPs, the "farv1_session/login" request MUST include at least one end-   
 1025    user identifier or OP Issuer Identifier.                                
 1026                                                                            
 1027    The server sets an HTTP cookie as described in [RFC6265] when the       
 1028    "farv1_session/login" request is received and processed successfully.   
 1029    The client MUST include the session cookie received from the server     
 1030    in any RDAP request within the scope of that session, including         
 1031    "farv1_session/refresh", "farv1_session/status", and "farv1_session/    
 1032    logout".  A "farv1_session/login" followed by another "farv1_session/   
 1033    login" that does not include an HTTP cookie MUST start a new session    
 1034    on the server that includes a new cookie.  A server that receives a     
 1035    "farv1_session/login" followed by another "farv1_session/login" that    
 1036    includes an HTTP cookie MUST return an HTTP 409 (Conflict) response.    
 1037                                                                            
 1038    To help reduce the risk of resource starvation, a server MAY reject a   
 1039    "farv1_session/login" request and refuse to start a new session by      
 1040    returning an HTTP 409 (Conflict) response if a server-side maximum      
 1041    number of concurrent sessions per user exists and the client exceeds    
 1042    that limit.  Additionally, an active session MAY be removed by the      
 1043    server due to timeout expiration or because a maximum session           
 1044    lifetime has been exceeded.  Clients SHOULD proactively monitor the     
 1045    "tokenExpiration" value associated with an active session and refresh   
 1046    the session as appropriate to provide a positive user experience.       
 1047                                                                            
 1048 5.2.1.  End-User Identifier                                                
 1049                                                                            
 1050    The end-user identifier is delivered using one of two methods: by       
 1051    adding a query component to an RDAP request URI using the syntax        
 1052    described in Section "application/x-www-form-urlencoded" of [HTMLURL]   
 1053    or by including an HTTP "authorization" request header for the Basic    
 1054    authentication scheme as described in [RFC7617].  Clients can use       
 1055    either of these methods to deliver the end-user identifier to a         
 1056    server that supports remote OPs and provider discovery.  Servers that   
 1057    support remote OPs and provider discovery MUST accept both methods.     
 1058    If the RDAP server supports a default OP or if provider discovery is    
 1059    not supported, the end-user identifier MAY be omitted.                  
 1060                                                                            
 1061    The query parameter used to deliver the end-user identifier is          
 1062    represented as an OPTIONAL "key=value" pair using a key value of        
 1063    "farv1_id" and a value component that contains the client identifier    
 1064    issued by an OP.  An example for client identifier                      
 1065    "user.idp.example":                                                     
 1066                                                                            
 1067    ========== NOTE: '\' line wrapping per RFC 8792 ===========             
 1068    https://example.com/rdap/farv1_session/\                                
 1069    login?farv1_id=user.idp.example                                         
 1070                                                                            
 1071                                   Figure 8                                 
 1072                                                                            
 1073    The authorization header for the Basic authentication scheme contains   
 1074    a base64-encoded representation of the client identifier issued by an   
 1075    OP.  No password is provided.  An example for client identifier         
 1076    "user.idp.example":                                                     
 1077                                                                            
 1078    https://example.com/rdap/farv1_session/login                            
 1079    Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ==                           
 1080                                                                            
 1081                                   Figure 9                                 
 1082                                                                            
 1083    An example for use with a default OP:                                   
 1084                                                                            
 1085    https://example.com/rdap/farv1_session/login                            
 1086                                                                            
 1087                                  Figure 10                                 
 1088                                                                            
 1089 5.2.2.  OP Issuer Identifier                                               
 1090                                                                            
 1091    The OP's Issuer Identifier is delivered by adding a query component     
 1092    to an RDAP request URI using the syntax described in Section            
 1093    "application/x-www-form-urlencoded" of [HTMLURL].  If the RDAP server   
 1094    supports a default OP, the Issuer Identifier MAY be omitted.            
 1095                                                                            
 1096    The query parameter used to deliver the OP's Issuer Identifier is       
 1097    represented as an OPTIONAL "key=value" pair using a key value of        
 1098    "farv1_iss" and a value component that contains the Issuer Identifier   
 1099    associated with an OP.  An RDAP server MAY accept Issuer Identifiers    
 1100    not specified in the "farv1_openidcConfiguration" data structure and    
 1101    MAY also decide to accept specific Issuer Identifiers only from         
 1102    specific clients.  An example for Issuer Identifier                     
 1103    "https://idp.example.com":                                              
 1104                                                                            
 1105    ========== NOTE: '\' line wrapping per RFC 8792 ===========             
 1106    https://example.com/rdap/farv1_session/\                                
 1107    login?farv1_iss=https://idp.example.com                                 
 1108                                                                            
 1109                                  Figure 11                                 
 1110                                                                            
 1111 5.2.3.  Login Response                                                     
 1112                                                                            
 1113    The response to this request MUST be a valid RDAP response per          
 1114    [RFC9083].  It MUST NOT include any members that relate to a specific   
 1115    RDAP object type (e.g., "events" or "status").  In addition, the        
 1116    response MAY include an indication of the requested operation's         
 1117    success or failure in the "notices" data structure.  If successful,     
 1118    the response MUST include a "farv1_session" data structure that         
 1119    includes a "sessionInfo" object and an OPTIONAL "userClaims" object.    
 1120    If unsuccessful, the response MUST include a "farv1_session" data       
 1121    structure that omits the "userClaims" and "sessionInfo" objects.        
 1122                                                                            
 1123    An example of a successful "farv1_session/login" response:              
 1124                                                                            
 1125        {                                                                   
 1126          "rdapConformance": [                                              
 1127            "farv1"                                                         
 1128          ],                                                                
 1129          "lang": "en-US",                                                  
 1130          "notices": [                                                      
 1131            {                                                               
 1132              "title": "Login Result",                                      
 1133              "description": [                                              
 1134                "Login succeeded"                                           
 1135              ]                                                             
 1136            }                                                               
 1137          ],                                                                
 1138          "farv1_session": {                                                
 1139            "userID": "user.idp.example",                                   
 1140            "iss": "https://idp.example.com",                               
 1141            "userClaims": {                                                 
 1142              "sub": "103892603076825016132",                               
 1143              "name": "User Person",                                        
 1144              "given_name": "User",                                         
 1145              "family_name": "Person",                                      
 1146              "picture": "https://lh3.example.com/a-/AOh14=s96-c",          
 1147              "email": "user@example.com",                                  
 1148              "email_verified": true,                                       
 1149              "locale": "en",                                               
 1150              "rdap_allowed_purposes": [                                    
 1151                "domainNameControl",                                        
 1152                "personalDataProtection"                                    
 1153              ],                                                            
 1154              "rdap_dnt_allowed": false                                     
 1155            },                                                              
 1156            "sessionInfo": {                                                
 1157              "tokenExpiration": 3599,                                      
 1158              "tokenRefresh": true                                          
 1159            }                                                               
 1160          }                                                                 
 1161        }                                                                   
 1162                                                                            
 1163                                  Figure 12                                 
 1164                                                                            
 1165    An example of a failed "farv1_session/login" response:                  
 1166                                                                            
 1167        {                                                                   
 1168          "rdapConformance": [                                              
 1169            "farv1"                                                         
 1170          ],                                                                
 1171          "lang": "en-US",                                                  
 1172          "notices": [                                                      
 1173            {                                                               
 1174              "title": "Login Result",                                      
 1175              "description": [                                              
 1176                "Login failed"                                              
 1177              ]                                                             
 1178            }                                                               
 1179          ],                                                                
 1180          "farv1_session": {                                                
 1181            "userID": "user.idp.example",                                   
 1182            "iss": "https://idp.example.com"                                
 1183          }                                                                 
 1184        }                                                                   
 1185                                                                            
 1186                                  Figure 13                                 
 1187                                                                            
 1188 5.2.4.  Clients with Limited User Interfaces                               
 1189                                                                            
 1190    "OAuth 2.0 Device Authorization Grant" [RFC8628] provides an OPTIONAL   
 1191    method to request user authorization from devices that have an          
 1192    Internet connection but lack a suitable browser for a more              
 1193    conventional OAuth flow.  This method requires an end user to use a     
 1194    second device (such as a smartphone) that has access to a web browser   
 1195    for entry of a code sequence that is presented on the UI-constrained    
 1196    device.                                                                 
 1197                                                                            
 1198 5.2.4.1.  UI-Constrained Client Login                                      
 1199                                                                            
 1200    Client authentication is requested by sending a "farv1_session/         
 1201    device" request to an RDAP server.  If the RDAP server supports only    
 1202    remote OPs, the "farv1_session/device" request MUST include either an   
 1203    end-user identifier as described in Section 5.2.1 or an OP Issuer       
 1204    Identifier as described in Section 5.2.2.                               
 1205                                                                            
 1206    An example using wget for client identifier "user.idp.example":         
 1207                                                                            
 1208    ========== NOTE: '\' line wrapping per RFC 8792 ===========             
 1209       wget -qO- "https://example.com/rdap/farv1_session/device\            
 1210       ?farv1_id=user.idp.example"                                          
 1211                                                                            
 1212                                  Figure 14                                 
 1213                                                                            
 1214    The authorization header for the Basic authentication scheme contains   
 1215    a base64-encoded representation of the client identifier issued by an   
 1216    OP.  No password is provided.                                           
 1217                                                                            
 1218    An example using curl and an authorization header:                      
 1219                                                                            
 1220    ========== NOTE: '\' line wrapping per RFC 8792 ===========             
 1221       curl -H "Authorization: Basic dXNlci5pZHAuZXhhbXBsZQ=="\             
 1222       "https://example.com/rdap/farv1_session/device"                      
 1223                                                                            
 1224                                  Figure 15                                 
 1225                                                                            
 1226    The response to this request MUST be a valid RDAP response per          
 1227    [RFC9083].  It MUST NOT include any members that relate to a specific   
 1228    RDAP object type (e.g., "events" or "status").  In addition, the        
 1229    response MAY include an indication of the requested operation's         
 1230    success or failure in the "notices" data structure and, if              
 1231    successful, a "farv1_deviceInfo" data structure.                        
 1232                                                                            
 1233    An example of a "farv1_session/device" response:                        
 1234                                                                            
 1235      {                                                                     
 1236        "rdapConformance": [                                                
 1237          "farv1"                                                           
 1238        ],                                                                  
 1239        "lang": "en-US",                                                    
 1240        "notices": [                                                        
 1241          {                                                                 
 1242            "title": "Device Login Result",                                 
 1243            "description": [                                                
 1244              "Login succeeded"                                             
 1245            ]                                                               
 1246          }                                                                 
 1247        ],                                                                  
 1248        "farv1_deviceInfo": {                                               
 1249          "device_code": "AH-1ng2ezu",                                      
 1250          "user_code": "NJJQ-GJFC",                                         
 1251          "verification_uri": "https://www.example.com/device",             
 1252          "verification_uri_complete":                                      
 1253                  "https://www.example.com/device?user_code=NJJQ-GJFC",     
 1254          "expires_in": 1800,                                               
 1255              "interval": 5                                                 
 1256        }                                                                   
 1257      }                                                                     
 1258                                                                            
 1259                                  Figure 16                                 
 1260                                                                            
 1261 5.2.4.2.  UI-Constrained Client Login Polling                              
 1262                                                                            
 1263    After successful processing of the "farv1_session/device" request,      
 1264    the client MUST send a "farv1_session/devicepoll" request to the RDAP   
 1265    server to continue the login process.  This request initiates the       
 1266    polling function described in [RFC8628] on the RDAP server.  The RDAP   
 1267    server polls the OP as described in Section 3.4 of [RFC8628],           
 1268    allowing the RDAP server to wait for the end user to enter the          
 1269    information returned from the "farv1_session/device" request using      
 1270    the interface on their second device.  After the end user has           
 1271    completed that process, or if the process fails or times out, the OP    
 1272    will respond to the polling requests with an indication of success or   
 1273    failure.  If the RDAP server supports only remote OPs, the              
 1274    "farv1_session/devicepoll" request MUST include either an end-user      
 1275    identifier as described in Section 5.2.1 or an OP Issuer Identifier     
 1276    as described in Section 5.2.2.                                          
 1277                                                                            
 1278    The "farv1_session/devicepoll" request MUST also include a "farv1_dc"   
 1279    query parameter.  The query parameter is represented as an OPTIONAL     
 1280    "key=value" pair using a key value of "farv1_dc" and a value            
 1281    component that contains the value of the device_code that was           
 1282    returned in the response to the "farv1_session/device" request.         
 1283                                                                            
 1284    An example using wget:                                                  
 1285                                                                            
 1286    ========== NOTE: '\' line wrapping per RFC 8792 ===========             
 1287       wget -qO- --keep-session-cookies --save-cookies cookie.txt\          
 1288       "https://example.com/rdap/farv1_session/devicepoll\                  
 1289       ?farv1_id=user.idp.example&farv1_dc=AH-1ng2ezu"                      
 1290                                                                            
 1291                                  Figure 17                                 
 1292                                                                            
 1293    An example using curl:                                                  
 1294                                                                            
 1295    ========== NOTE: '\' line wrapping per RFC 8792 ===========             
 1296       curl -c cookie.txt "https://example.com/rdap/farv1_session/\         
 1297       devicepoll?farv1_id=user.idp.example&farv1_dc=AH-1ng2ezu"            
 1298                                                                            
 1299                                  Figure 18                                 
 1300                                                                            
 1301    The response to this request MUST use the response structures           
 1302    described in Section 5.2.  RDAP query processing can continue           
 1303    normally on the UI-constrained device once the device polling process   
 1304    has been completed successfully.                                        
 1305                                                                            
 1306 5.3.  Session Status                                                       
 1307                                                                            
 1308    Clients MAY send a query to an RDAP server to determine the status of   
 1309    an existing login session using a "farv1_session/status" path           
 1310    segment.  An example "farv1_session/status" request:                    
 1311                                                                            
 1312    https://example.com/rdap/farv1_session/status                           
 1313                                                                            
 1314                                  Figure 19                                 
 1315                                                                            
 1316    The response to this request MUST be a valid RDAP response per          
 1317    [RFC9083].  It MUST NOT include any members that relate to a specific   
 1318    RDAP object type (e.g., "events" or "status").  In addition, the        
 1319    response MAY include an indication of the requested operation's         
 1320    success or failure in the "notices" data structure.  If the operation   
 1321    is successful and an active session exists, the response MUST include   
 1322    a "farv1_session" data structure that includes a "sessionInfo" object   
 1323    and an OPTIONAL "userClaims" object.  If the operation is               
 1324    unsuccessful or if no active session exists, the response MUST NOT      
 1325    include a "farv1_session" object.                                       
 1326                                                                            
 1327    An example of a "farv1_session/status" response for an active           
 1328    session:                                                                
 1329                                                                            
 1330      {                                                                     
 1331        "rdapConformance": [                                                
 1332          "farv1"                                                           
 1333        ],                                                                  
 1334        "lang": "en-US",                                                    
 1335        "notices": [                                                        
 1336          {                                                                 
 1337            "title": "Session Status Result",                               
 1338            "description": [                                                
 1339              "Session status succeeded"                                    
 1340            ]                                                               
 1341          }                                                                 
 1342        ],                                                                  
 1343        "farv1_session": {                                                  
 1344          "userID": "user.idp.example",                                     
 1345          "iss": "https://idp.example.com",                                 
 1346          "userClaims": {                                                   
 1347            "sub": "103892603076825016132",                                 
 1348            "name": "User Person",                                          
 1349            "given_name": "User",                                           
 1350            "family_name": "Person",                                        
 1351            "picture": "https://lh3.example.com/a-/AOh14=s96-c",            
 1352            "email": "user@example.com",                                    
 1353            "email_verified": true,                                         
 1354            "locale": "en",                                                 
 1355            "rdap_allowed_purposes": [                                      
 1356              "domainNameControl",                                          
 1357              "personalDataProtection"                                      
 1358            ],                                                              
 1359            "rdap_dnt_allowed": false                                       
 1360          },                                                                
 1361          "sessionInfo": {                                                  
 1362            "tokenExpiration": 3490,                                        
 1363            "tokenRefresh": true                                            
 1364          }                                                                 
 1365        }                                                                   
 1366      }                                                                     
 1367                                                                            
 1368                                  Figure 20                                 
 1369                                                                            
 1370    If the operation is successful and an active session does not exist,    
 1371    the response MAY note the lack of an active session in the "notices"    
 1372    data structure.  The "farv1_session" data structure MUST be omitted.    
 1373                                                                            
 1374    An example of a "farv1_session/status" response with no active          
 1375    session:                                                                
 1376                                                                            
 1377      {                                                                     
 1378        "rdapConformance": [                                                
 1379          "farv1"                                                           
 1380        ],                                                                  
 1381        "lang": "en-US",                                                    
 1382        "notices": [                                                        
 1383          {                                                                 
 1384            "title": "Session Status Result",                               
 1385            "description": [                                                
 1386              "Session status succeeded",                                   
 1387              "No active session"                                           
 1388            ]                                                               
 1389          }                                                                 
 1390        ]                                                                   
 1391      }                                                                     
 1392                                                                            
 1393                                  Figure 21                                 
 1394                                                                            
 1395 5.4.  Session Refresh                                                      
 1396                                                                            
 1397    Clients MAY send a request to an RDAP server to refresh or extend an    
 1398    existing login session using a "farv1_session/refresh" path segment.    
 1399    The RDAP server MAY attempt to refresh the access token associated      
 1400    with the current session as part of extending the session for a         
 1401    period of time determined by the RDAP server.  As described in          
 1402    [RFC6749], OP support for refresh tokens is OPTIONAL.  An RDAP server   
 1403    MUST determine if the OP supports token refresh and process the         
 1404    refresh request by either requesting refresh of the access token or     
 1405    returning a response that indicates that token refresh is not           
 1406    supported by the OP in the "notices" data structure.  An example        
 1407    "farv1_session/refresh" request:                                        
 1408                                                                            
 1409    https://example.com/rdap/farv1_session/refresh                          
 1410                                                                            
 1411                                  Figure 22                                 
 1412                                                                            
 1413    The response to this request MUST be a valid RDAP response per          
 1414    [RFC9083].  It MUST NOT include any members that relate to a specific   
 1415    RDAP object type (e.g., "events" or "status").  In addition, the        
 1416    response MAY include an indication of the requested operation's         
 1417    success or failure in the "notices" data structure.  The response       
 1418    MUST include a "farv1_session" data structure that includes a           
 1419    "sessionInfo" object and an OPTIONAL "userClaims" object.  If           
 1420    unsuccessful but an active session exists, the response MUST include    
 1421    a "farv1_session" data structure that includes a "sessionInfo" object   
 1422    and an OPTIONAL "userClaims" object.  If unsuccessful and no active     
 1423    session exists, the response MUST omit the "farv1_session" data         
 1424    structure.                                                              
 1425                                                                            
 1426    An example of a successful "farv1_session/refresh" response:            
 1427                                                                            
 1428      {                                                                     
 1429        "rdapConformance": [                                                
 1430          "farv1"                                                           
 1431        ],                                                                  
 1432        "lang": "en-US",                                                    
 1433        "notices": [                                                        
 1434          {                                                                 
 1435            "title": "Session Refresh Result",                              
 1436            "description": [                                                
 1437              "Session refresh succeeded",                                  
 1438              "Token refresh succeeded."                                    
 1439            ]                                                               
 1440          }                                                                 
 1441        ],                                                                  
 1442        "farv1_session": {                                                  
 1443          "userID": "user.idp.example",                                     
 1444          "iss": "https://idp.example.com",                                 
 1445          "userClaims": {                                                   
 1446            "sub": "103892603076825016132",                                 
 1447            "name": "User Person",                                          
 1448            "given_name": "User",                                           
 1449            "family_name": "Person",                                        
 1450            "picture": "https://lh3.example.com/a-/AOh14=s96-c",            
 1451            "email": "user@example.com",                                    
 1452            "email_verified": true,                                         
 1453            "locale": "en",                                                 
 1454            "rdap_allowed_purposes": [                                      
 1455              "domainNameControl",                                          
 1456              "personalDataProtection"                                      
 1457            ],                                                              
 1458            "rdap_dnt_allowed": false                                       
 1459          },                                                                
 1460          "sessionInfo": {                                                  
 1461            "tokenExpiration": 3599,                                        
 1462            "tokenRefresh": true                                            
 1463          }                                                                 
 1464        }                                                                   
 1465      }                                                                     
 1466                                                                            
 1467                                  Figure 23                                 
 1468                                                                            
 1469    Alternatively, an RDAP server MAY attempt to refresh an access token    
 1470    upon receipt of a query if the access token associated with an          
 1471    existing session has expired and the corresponding OP supports token    
 1472    refresh.  The default RDAP server behavior is described in the          
 1473    "implicitTokenRefreshSupported" value that's included in the            
 1474    "farv1_openidcConfiguration" data structure (see Section 4.1).          
 1475                                                                            
 1476    If the value of "implicitTokenRefreshSupported" is "true", the client   
 1477    MAY either explicitly attempt to refresh the session using the          
 1478    "farv1_session/refresh" query or depend on the RDAP server to attempt   
 1479    to refresh the session as necessary when an RDAP query is received by   
 1480    the server.  In this case, a server MUST attempt to refresh the         
 1481    access token upon receipt of a query if the access token associated     
 1482    with an existing session has expired and the corresponding OP           
 1483    supports token refresh.  Servers MUST return an HTTP 401                
 1484    (Unauthorized) response to a query if an attempt to implicitly          
 1485    refresh an existing session fails.                                      
 1486                                                                            
 1487    If the value of "implicitTokenRefreshSupported" is "false", the         
 1488    client MUST explicitly attempt to refresh the session using the         
 1489    "farv1_session/refresh" query to extend an existing session.  If a      
 1490    session cannot be extended for any reason, the client MUST establish    
 1491    a new session to continue authenticated query processing by             
 1492    submitting a "farv1_session/login" query.  If the OP does not support   
 1493    token refresh, the client MUST submit a new "farv1_session/login"       
 1494    request to establish a new session once an access token has expired.    
 1495                                                                            
 1496    Clients SHOULD NOT send a "farv1_session/refresh" request in the        
 1497    absence of an active login session because the request conflicts with   
 1498    the current state of the server.  Servers MUST return an HTTP 409       
 1499    (Conflict) response if a "farv1_session/refresh" request is received    
 1500    in the absence of a session cookie.                                     
 1501                                                                            
 1502 5.5.  Client Logout                                                        
 1503                                                                            
 1504    Clients MAY send a request to an RDAP server to terminate an existing   
 1505    login session.  Termination of a session is requested using a           
 1506    "farv1_session/logout" path segment.  Access and refresh tokens can     
 1507    be revoked during the "farv1_session/logout" process as described in    
 1508    [RFC7009] if supported by the OP (token revocation endpoint support     
 1509    is OPTIONAL per [RFC8414]).  If supported, this feature SHOULD be       
 1510    used to ensure that the tokens are not mistakenly associated with a     
 1511    future RDAP session.  Alternatively, an RDAP server MAY attempt to      
 1512    log out from the OP using the OpenID Connect RP-Initiated Logout        
 1513    protocol [OIDCL] if that protocol is supported by the OP.  In any       
 1514    case, to prevent abuse before the cookie times out, an RDAP server      
 1515    SHOULD invalidate the HTTP cookie associated with the session as part   
 1516    of terminating the session.                                             
 1517                                                                            
 1518    An example "farv1_session/logout" request:                              
 1519                                                                            
 1520    https://example.com/rdap/farv1_session/logout                           
 1521                                                                            
 1522                                  Figure 24                                 
 1523                                                                            
 1524    The response to this request MUST be a valid RDAP response per          
 1525    [RFC9083].  It MUST NOT include any members that relate to a specific   
 1526    RDAP object type (e.g., "events" or "status").  In addition, the        
 1527    response MAY include an indication of the requested operation's         
 1528    success or failure in the "notices" data structure.  The "notices"      
 1529    data structure MAY include an indication of the success or failure of   
 1530    any attempt to logout from the OP or to revoke the tokens issued by     
 1531    the OP.                                                                 
 1532                                                                            
 1533    An example of a "farv1_session/logout" response:                        
 1534                                                                            
 1535      {                                                                     
 1536        "rdapConformance": [                                                
 1537          "farv1"                                                           
 1538        ],                                                                  
 1539        "lang": "en-US",                                                    
 1540        "notices": [                                                        
 1541          {                                                                 
 1542            "title": "Logout Result",                                       
 1543            "description": [                                                
 1544              "Logout succeeded"                                            
 1545              "Provider logout failed: Not supported by provider.",         
 1546              "Token revocation successful."                                
 1547            ]                                                               
 1548          }                                                                 
 1549        ]                                                                   
 1550      }                                                                     
 1551                                                                            
 1552                                  Figure 25                                 
 1553                                                                            
 1554    In the absence of a "logout" request, an RDAP session MUST be           
 1555    terminated by the RDAP server after a server-defined period of time.    
 1556    The server SHOULD also take appropriate steps to ensure that the        
 1557    tokens associated with the terminated session cannot be reused.  This   
 1558    SHOULD include revoking the tokens or logging out from the OP if        
 1559    either operation is supported by the OP.                                
 1560                                                                            
 1561 5.6.  Request Sequencing                                                   
 1562                                                                            
 1563    The requests described in this document are typically performed in a    
 1564    specific sequence:                                                      
 1565                                                                            
 1566    1.  "farv1_session/login" (or the related "farv1_session/device" and    
 1567        "farv1_session/devicepoll" requests) to start a session,            
 1568                                                                            
 1569    2.  "farv1_session/status" and/or "farv1_session/refresh" to manage a   
 1570        session,                                                            
 1571                                                                            
 1572    3.  and "farv1_session/logout" to end a session.                        
 1573                                                                            
 1574    If a client sends a "farv1_session/status", "farv1_session/refresh",    
 1575    or "farv1_session/logout" request in the absence of a session cookie,   
 1576    the server MUST return an HTTP 409 (Conflict) error.                    
 1577                                                                            
 1578    A client can end a session explicitly by sending a "farv1_session/      
 1579    logout" request to the RDAP server.  A session can also be ended        
 1580    implicitly by the server after a server-defined period of time.  The    
 1581    status of a session can be determined at any time by sending a          
 1582    "farv1_session/status" query to the RDAP server.                        
 1583                                                                            
 1584    An RDAP server MUST maintain session state information for the          
 1585    duration of an active session.  This is commonly done using HTTP        
 1586    cookies as described in [RFC6265].  Doing so allows end users to        
 1587    submit queries without having to explicitly identify and authenticate   
 1588    themselves for every query.                                             
 1589                                                                            
 1590    An RDAP server can receive queries that include a session cookie        
 1591    where the associated session has expired or is otherwise unavailable    
 1592    (e.g., due to the user requesting explicit logout for the associated    
 1593    session).  The server MUST return an HTTP 401 (Unauthorized) error in   
 1594    response to such queries.                                               
 1595                                                                            
 1596 6.  Protocol Features for Token-Oriented Clients                           
 1597                                                                            
 1598    This specification adds additional processing steps for token-          
 1599    oriented clients as described in this section and Section 3.1.3.  It    
 1600    does not define additional data structures or RDAP-specific protocol    
 1601    parameters specifically for token-oriented clients.                     
 1602                                                                            
 1603 6.1.  Client Login                                                         
 1604                                                                            
 1605    Clients identify and authenticate end users by exchanging information   
 1606    with an OP that is recognized by the RDAP server as described in        
 1607    Sections 3.1.4.2, 3.1.4.3, and 3.1.4.4.  A client SHOULD append the     
 1608    "additionalAuthorizationQueryParams" values retrieved from the          
 1609    "openidcProviders" array described in Section 4.1 to the                
 1610    authorization endpoint URL when requesting authorization from the OP.   
 1611    Once these processes are completed successfully, the client can         
 1612    request tokens from the OP as described in Section 3.1.4.5.  The OP     
 1613    SHOULD include the RDAP server's client_id in the "aud" claim value     
 1614    of an issued ID Token.  The RDAP server MAY choose to ignore the        
 1615    value of the "aud" claim or exchange the token as described in          
 1616    Section 6.4.  With these steps completed, the access token received     
 1617    from the OP can be passed to an RDAP server in an HTTP                  
 1618    "authorization" request header [RFC6750] for RDAP queries that          
 1619    require end-user identification, authentication, and authorization.     
 1620                                                                            
 1621 6.2.  Client Queries                                                       
 1622                                                                            
 1623    An RDAP server that receives a bearer token in an HTTP                  
 1624    "authorization" request header as part of an RDAP object query MUST     
 1625    validate the token in accordance with local policy and confirm that     
 1626    the token is a legitimate access token.  Once validated, the access     
 1627    token MAY be used to retrieve the claims associated with the end        
 1628    user's identity, including claims associated with the "rdap" scope      
 1629    that are not already included in the access token, as described in      
 1630    Section 3.1.4.6.  The RDAP server can then evaluate the end user's      
 1631    identity information to determine the end user's authorization level    
 1632    and process the query in accordance with server policies.  A client     
 1633    MUST include the "farv1_iss" query parameter and Issuer Identifier      
 1634    value with an RDAP query if the token was issued by a remote OP.        
 1635                                                                            
 1636 6.3.  Access Token Validation                                              
 1637                                                                            
 1638    An RDAP server MUST validate a received access token prior to using     
 1639    that token for access control purposes.  Validation MAY include token   
 1640    introspection [RFC7662] using the issuing OP or analysis of the         
 1641    values included in a JWT access token.  Once an access token is         
 1642    validated, an RDAP server MAY use that token to request user claims     
 1643    from the issuing OP.                                                    
 1644                                                                            
 1645    There are performance considerations associated with the process of     
 1646    validating a token and requesting user claims as part of processing     
 1647    every received RDAP query.  An RDAP server MAY cache validated          
 1648    information and use that cached information to reduce the amount of     
 1649    time needed to process subsequent RDAP queries associated with the      
 1650    same access token as long as the token has not expired.  The client     
 1651    SHOULD monitor the token expiration time and refresh the token as       
 1652    needed.                                                                 
 1653                                                                            
 1654 6.4.  Token Exchange                                                       
 1655                                                                            
 1656    Tokens can include an "aud" (audience) claim that contains the OAuth    
 1657    2.0 client_id of the RP as an audience value.  In some operational      
 1658    scenarios (such as a client that is providing a proxy service), an RP   
 1659    can receive tokens with an "aud" claim value that does not include      
 1660    the RP's client_id.  These tokens might not be trusted by the RP, and   
 1661    the RP might refuse to accept the tokens.  This situation can be        
 1662    remedied by having the RP exchange the access token with the OP for a   
 1663    set of trusted tokens that reset the "aud" claim.  The token exchange   
 1664    protocol is described in [RFC8693].                                     
 1665                                                                            
 1666 7.  RDAP Query Processing                                                  
 1667                                                                            
 1668    Once an RDAP session is active, an RDAP server MUST determine if the    
 1669    end user is authorized to perform any queries that are received         
 1670    during the duration of the session.  This MAY include rejecting         
 1671    queries outright, and it MAY include omitting or otherwise redacting    
 1672    information that the end user is not authorized to receive.  Specific   
 1673    processing requirements are beyond the scope of this document.          
 1674                                                                            
 1675 8.  RDAP Conformance                                                       
 1676                                                                            
 1677    RDAP responses that contain values described in this document MUST      
 1678    indicate conformance with this specification by including an            
 1679    rdapConformance [RFC9083] value of "farv1" (federated authentication    
 1680    method for RDAP version 1).  The information needed to register this    
 1681    value in the "RDAP Extensions" registry is described in Section 9.1.    
 1682                                                                            
 1683    Example rdapConformance structure with extension specified:             
 1684                                                                            
 1685       "rdapConformance" :                                                  
 1686         [                                                                  
 1687           "rdap_level_0",                                                  
 1688           "farv1"                                                          
 1689         ]                                                                  
 1690                                                                            
 1691                                  Figure 26                                 
 1692                                                                            
 1693 9.  IANA Considerations                                                    
 1694                                                                            
 1695 9.1.  RDAP Extensions Registry                                             
 1696                                                                            
 1697    IANA has registered the following value in the "RDAP Extensions"        
 1698    registry:                                                               
 1699                                                                            
 1700    Extension Identifier:  farv1                                            
 1701    Registry Operator:  Any                                                 
 1702    Specification:  RFC 9560                                                
 1703    Contact:  IETF <iesg@ietf.org>                                          
 1704    Intended Usage:  This extension describes federated authentication      
 1705       method for RDAP version 1 using OAuth 2.0 and OpenID Connect.        
 1706                                                                            
 1707 9.2.  JSON Web Token Claims Registry                                       
 1708                                                                            
 1709    IANA has registered the following values in the "JSON Web Token         
 1710    Claims" registry:                                                       
 1711                                                                            
 1712    Claim Name:  rdap_allowed_purposes                                      
 1713    Claim Description:  This claim describes the set of RDAP query          
 1714       purposes that are available to an identity that is presented for     
 1715       access to a protected RDAP resource.                                 
 1716    Change Controller:  IETF                                                
 1717    Reference:  Section 3.1.5.1 of RFC 9560.                                
 1718                                                                            
 1719    Claim Name:  rdap_dnt_allowed                                           
 1720    Claim Description:  This claim contains a JSON boolean literal that     
 1721       describes a "do not track" request for server-side tracking,         
 1722       logging, or recording of an identity that is presented for access    
 1723       to a protected RDAP resource.                                        
 1724    Change Controller:  IETF                                                
 1725    Reference:  Section 3.1.5.2 of RFC 9560.                                
 1726                                                                            
 1727 9.3.  RDAP Query Purpose Registry                                          
 1728                                                                            
 1729    IANA has created a new protocol registry to manage RDAP query purpose   
 1730    values.                                                                 
 1731                                                                            
 1732    Section at https://www.iana.org/protocols:  Registration Data Access    
 1733       Protocol (RDAP)                                                      
 1734    Registry Name:  Registration Data Access Protocol (RDAP) Query          
 1735       Purpose Values                                                       
 1736    Registration Procedure(s):  This registry is operated under the         
 1737       "Specification Required" policy defined in [RFC8126].  The           
 1738       designated expert must ensure that requests to add values to this    
 1739       registry meet the syntax, value, and description requirements        
 1740       described in this section.                                           
 1741    Required Information:  Registration requests are described in a         
 1742       specification that's consistent with the "Specification Required"    
 1743       policy defined in [RFC8126].  The specification must include one     
 1744       or more purpose values as described below.                           
 1745                                                                            
 1746    Individual purpose values are registered with IANA.  Each entry in      
 1747    the registry contains the following fields:                             
 1748                                                                            
 1749    Value:  The purpose string value being registered.  Value strings can   
 1750       contain uppercase ASCII characters from "A" to "Z", lowercase        
 1751       ASCII characters from "a" to "z", and the underscore ("_")           
 1752       character.  Value strings contain at least one character and no      
 1753       more than 64 characters.                                             
 1754    Description:  One or two sentences in English describing the meaning    
 1755       of the purpose value, how it might be used, and/or how it should     
 1756       be interpreted by clients and servers.                               
 1757    Reference:  RFC 9560                                                    
 1758                                                                            
 1759    The set of initial values used to populate the registry as described    
 1760    below are derived from the final report produced by the Expert          
 1761    Working Group on gTLD Directory Services chartered by the Internet      
 1762    Corporation for Assigned Names and Numbers (ICANN) [gTLD].              
 1763                                                                            
 1764    Value:  domainNameControl                                               
 1765    Description:  Tasks within the scope of this purpose include, for a     
 1766       registrant's own domain name, creating the domain name, updating     
 1767       information about the domain name, transferring the domain name,     
 1768       renewing the domain name, deleting the domain name, maintaining a    
 1769       domain name portfolio, and detecting fraudulent use of the           
 1770       registrant's own contact information.                                
 1771    Reference:  RFC 9560                                                    
 1772                                                                            
 1773    Value:  personalDataProtection                                          
 1774    Description:  Tasks within the scope of this purpose include            
 1775       identifying the accredited privacy or proxy provider associated      
 1776       with a domain name, reporting abuse, requesting reveal, or           
 1777       otherwise contacting the provider.                                   
 1778    Reference:  RFC 9560                                                    
 1779                                                                            
 1780    Value:  technicalIssueResolution                                        
 1781    Description:  Tasks within the scope of this purpose include (but are   
 1782       not limited to) working to resolve technical issues, including       
 1783       email delivery issues, DNS resolution failures, and website          
 1784       functionality issues.                                                
 1785    Reference:  RFC 9560                                                    
 1786                                                                            
 1787    Value:  domainNameCertification                                         
 1788    Description:  Tasks within the scope of this purpose include a          
 1789       Certification Authority (CA) issuing an X.509 certificate to a       
 1790       subject identified by a domain name.                                 
 1791    Reference:  RFC 9560                                                    
 1792                                                                            
 1793    Value:  individualInternetUse                                           
 1794    Description:  Tasks within the scope of this purpose include            
 1795       identifying the organization using a domain name to instill          
 1796       consumer trust or contacting that organization to raise a customer   
 1797       complaint to them or file a complaint about them.                    
 1798    Reference:  RFC 9560                                                    
 1799                                                                            
 1800    Value:  businessDomainNamePurchaseOrSale                                
 1801    Description:  Tasks within the scope of this purpose include making     
 1802       purchase queries about a domain name, acquiring a domain name from   
 1803       a registrant, and enabling due diligence research.                   
 1804    Reference:  RFC 9560                                                    
 1805                                                                            
 1806    Value:  academicPublicInterestDNSResearch                               
 1807    Description:  Tasks within the scope of this purpose include academic   
 1808       public interest research studies about domain names published in     
 1809       the registration data service, including public information about    
 1810       the registrant and designated contacts, the domain name's history    
 1811       and status, and domain names registered by a given registrant        
 1812       (reverse query).                                                     
 1813    Reference:  RFC 9560                                                    
 1814                                                                            
 1815    Value:  legalActions                                                    
 1816    Description:  Tasks within the scope of this purpose include            
 1817       investigating possible fraudulent use of a registrant's name or      
 1818       address by other domain names, investigating possible trademark      
 1819       infringement, contacting a registrant's or licensee's legal          
 1820       representative prior to taking legal action, and then taking a       
 1821       legal action if the concern is not satisfactorily addressed.         
 1822    Reference:  RFC 9560                                                    
 1823                                                                            
 1824    Value:  regulatoryAndContractEnforcement                                
 1825    Description:  Tasks within the scope of this purpose include            
 1826       investigating the tax authority of businesses with online            
 1827       presences, investigating Uniform Domain-Name Dispute-Resolution      
 1828       Policy (UDRP), investigating contractual compliance, and             
 1829       registering data escrow audits.                                      
 1830    Reference:  RFC 9560                                                    
 1831                                                                            
 1832    Value:  criminalInvestigationAndDNSAbuseMitigation                      
 1833    Description:  Tasks within the scope of this purpose include            
 1834       reporting abuse to someone who can investigate and address that      
 1835       abuse or contacting entities associated with a domain name during    
 1836       an offline criminal investigation.                                   
 1837    Reference:  RFC 9560                                                    
 1838                                                                            
 1839    Value:  dnsTransparency                                                 
 1840    Description:  Tasks within the scope of this purpose involve querying   
 1841       the registration data made public by registrants to satisfy a wide   
 1842       variety of use cases around informing the public.                    
 1843    Reference:  RFC 9560                                                    
 1844                                                                            
 1845 10.  Security Considerations                                               
 1846                                                                            
 1847    Security considerations for RDAP can be found in [RFC7481].  Security   
 1848    considerations for OpenID Connect Core [OIDCC] and OAuth 2.0            
 1849    [RFC6749] can be found in their reference specifications; best          
 1850    current security practice for OAuth 2.0 can be found in                 
 1851    [OAUTH-SECURITY].  Additionally, the practices described in [RFC9325]   
 1852    MUST be followed when the Transport Layer Security (TLS) protocol is    
 1853    used.                                                                   
 1854                                                                            
 1855    As described in Section 3.1.4.2, the OAuth 2.0 Implicit Flow            
 1856    [RFC6749] is considered insecure, and efforts are being made to         
 1857    deprecate the flow.  It MUST NOT be used.                               
 1858                                                                            
 1859    Some of the responses described in this specification return            
 1860    information to a client from an RDAP server that is intended to help    
 1861    the client match responses to queries and manage sessions.  Some of     
 1862    that information, such as the "userClaims" described in                 
 1863    Section 5.1.1, can be personally identifiable and considered            
 1864    sensitive if disclosed to unauthorized parties.  An RDAP server         
 1865    operator must develop policies for information disclosure to ensure     
 1866    that personally identifiable information is disclosed only to clients   
 1867    that are authorized to process that information.                        
 1868                                                                            
 1869    The "do not track" claim relies on the good will of the RDAP server     
 1870    and associated proxies.  As such, using and processing this claim       
 1871    depends on out-of-band trust relationships that need to be              
 1872    established before the claim is used in practice.  If used and          
 1873    accepted by the RDAP server, there is a risk of information loss that   
 1874    could seriously impair audit capabilities.                              
 1875                                                                            
 1876 10.1.  Authentication and Access Control                                   
 1877                                                                            
 1878    Having completed the client identification, authorization, and          
 1879    validation process, an RDAP server can make access control decisions    
 1880    based on a comparison of client-provided information (such as the set   
 1881    of "userClaims" described in Section 5.1.1) and local policy.  For      
 1882    example, a client who provides an email address (and nothing more)      
 1883    might be entitled to receive a subset of the information that would     
 1884    be available to a client who provides an email address, a full name,    
 1885    and a stated purpose.  Development of these access control policies     
 1886    is beyond the scope of this document.                                   
 1887                                                                            
 1888 11.  References                                                            
 1889                                                                            
 1890 11.1.  Normative References                                                
 1891                                                                            
 1892    [HTMLURL]  WHATWG, "URL (Living Standard)", March 2024,                 
 1893               <https://url.spec.whatwg.org/>.                              
 1894                                                                            
 1895    [OIDCC]    Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and   
 1896               C. Mortimore, "OpenID Connect Core 1.0 incorporating         
 1897               errata set 2", December 2023,                                
 1898               <https://openid.net/specs/openid-connect-core-1_0.html>.     
 1899                                                                            
 1900    [OIDCD]    Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID    
 1901               Connect Discovery 1.0 incorporating errata set 2",           
 1902               December 2023, <https://openid.net/specs/openid-connect-     
 1903               discovery-1_0.html>.                                         
 1904                                                                            
 1905    [OIDCL]    Jones, M., de Medeiros, B., Agarwal, N., Sakimura, N., and   
 1906               J. Bradley, "OpenID Connect RP-Initiated Logout 1.0",        
 1907               September 2022, <https://openid.net/specs/openid-connect-    
 1908               rpinitiated-1_0.html>.                                       
 1909                                                                            
 1910    [OIDCR]    Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect     
 1911               Dynamic Client Registration 1.0 incorporating errata set     
 1912               2", December 2023, <https://openid.net/specs/openid-         
 1913               connect-registration-1_0.html>.                              
 1914                                                                            
 1915    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1916               Requirement Levels", BCP 14, RFC 2119,                       
 1917               DOI 10.17487/RFC2119, March 1997,                            
 1918               <https://www.rfc-editor.org/info/rfc2119>.                   
 1919                                                                            
 1920    [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,      
 1921               DOI 10.17487/RFC6265, April 2011,                            
 1922               <https://www.rfc-editor.org/info/rfc6265>.                   
 1923                                                                            
 1924    [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",     
 1925               RFC 6749, DOI 10.17487/RFC6749, October 2012,                
 1926               <https://www.rfc-editor.org/info/rfc6749>.                   
 1927                                                                            
 1928    [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization         
 1929               Framework: Bearer Token Usage", RFC 6750,                    
 1930               DOI 10.17487/RFC6750, October 2012,                          
 1931               <https://www.rfc-editor.org/info/rfc6750>.                   
 1932                                                                            
 1933    [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth   
 1934               2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,       
 1935               August 2013, <https://www.rfc-editor.org/info/rfc7009>.      
 1936                                                                            
 1937    [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the    
 1938               Registration Data Access Protocol (RDAP)", STD 95,           
 1939               RFC 7480, DOI 10.17487/RFC7480, March 2015,                  
 1940               <https://www.rfc-editor.org/info/rfc7480>.                   
 1941                                                                            
 1942    [RFC7481]  Hollenbeck, S. and N. Kong, "Security Services for the       
 1943               Registration Data Access Protocol (RDAP)", STD 95,           
 1944               RFC 7481, DOI 10.17487/RFC7481, March 2015,                  
 1945               <https://www.rfc-editor.org/info/rfc7481>.                   
 1946                                                                            
 1947    [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token     
 1948               (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,            
 1949               <https://www.rfc-editor.org/info/rfc7519>.                   
 1950                                                                            
 1951    [RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",       
 1952               RFC 7617, DOI 10.17487/RFC7617, September 2015,              
 1953               <https://www.rfc-editor.org/info/rfc7617>.                   
 1954                                                                            
 1955    [RFC7662]  Richer, J., Ed., "OAuth 2.0 Token Introspection",            
 1956               RFC 7662, DOI 10.17487/RFC7662, October 2015,                
 1957               <https://www.rfc-editor.org/info/rfc7662>.                   
 1958                                                                            
 1959    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for        
 1960               Writing an IANA Considerations Section in RFCs", BCP 26,     
 1961               RFC 8126, DOI 10.17487/RFC8126, June 2017,                   
 1962               <https://www.rfc-editor.org/info/rfc8126>.                   
 1963                                                                            
 1964    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
 1965               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
 1966               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
 1967                                                                            
 1968    [RFC8628]  Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,      
 1969               "OAuth 2.0 Device Authorization Grant", RFC 8628,            
 1970               DOI 10.17487/RFC8628, August 2019,                           
 1971               <https://www.rfc-editor.org/info/rfc8628>.                   
 1972                                                                            
 1973    [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,      
 1974               and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,      
 1975               DOI 10.17487/RFC8693, January 2020,                          
 1976               <https://www.rfc-editor.org/info/rfc8693>.                   
 1977                                                                            
 1978    [RFC9068]  Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0    
 1979               Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October      
 1980               2021, <https://www.rfc-editor.org/info/rfc9068>.             
 1981                                                                            
 1982    [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access      
 1983               Protocol (RDAP) Query Format", STD 95, RFC 9082,             
 1984               DOI 10.17487/RFC9082, June 2021,                             
 1985               <https://www.rfc-editor.org/info/rfc9082>.                   
 1986                                                                            
 1987    [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the        
 1988               Registration Data Access Protocol (RDAP)", STD 95,           
 1989               RFC 9083, DOI 10.17487/RFC9083, June 2021,                   
 1990               <https://www.rfc-editor.org/info/rfc9083>.                   
 1991                                                                            
 1992    [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,      
 1993               Ed., "HTTP Semantics", STD 97, RFC 9110,                     
 1994               DOI 10.17487/RFC9110, June 2022,                             
 1995               <https://www.rfc-editor.org/info/rfc9110>.                   
 1996                                                                            
 1997    [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,                
 1998               "Recommendations for Secure Use of Transport Layer           
 1999               Security (TLS) and Datagram Transport Layer Security         
 2000               (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November   
 2001               2022, <https://www.rfc-editor.org/info/rfc9325>.             
 2002                                                                            
 2003 11.2.  Informative References                                              
 2004                                                                            
 2005    [gTLD]     Expert Working Group on gTLD Directory Services (EWG),       
 2006               "Final Report from the Expert Working Group on gTLD          
 2007               Directory Services: A Next-Generation Registration           
 2008               Directory Service (RDS)", June 2014,                         
 2009               <https://www.icann.org/en/system/files/files/final-report-   
 2010               06jun14-en.pdf>.                                             
 2011                                                                            
 2012    [OAUTH-SECURITY]                                                        
 2013               Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,     
 2014               "OAuth 2.0 Security Best Current Practice", Work in          
 2015               Progress, Internet-Draft, draft-ietf-oauth-security-         
 2016               topics-26, 21 April 2024,                                    
 2017               <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-     
 2018               security-topics-26>.                                         
 2019                                                                            
 2020    [OIDC]     OpenID, "What is OpenID Connect",                            
 2021               <https://openid.net/developers/how-connect-works/>.          
 2022                                                                            
 2023    [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",         
 2024               FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,         
 2025               <https://www.rfc-editor.org/info/rfc4949>.                   
 2026                                                                            
 2027    [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0          
 2028               Authorization Server Metadata", RFC 8414,                    
 2029               DOI 10.17487/RFC8414, June 2018,                             
 2030               <https://www.rfc-editor.org/info/rfc8414>.                   
 2031                                                                            
 2032    [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,            
 2033               "Handling Long Lines in Content of Internet-Drafts and       
 2034               RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,            
 2035               <https://www.rfc-editor.org/info/rfc8792>.                   
 2036                                                                            
 2037 Acknowledgments                                                            
 2038                                                                            
 2039    The author would like to acknowledge the following individuals for      
 2040    their contributions to the development of this document: Julien         
 2041    Bernard, Marc Blanchet, Tom Harrison, Russ Housley, Jasdip Singh,       
 2042    Rhys Smith, Jaromir Talir, Rick Wilhelm, and Alessandro Vesely.  In     
 2043    addition, the Verisign Registry Services Lab development team of        
 2044    Joseph Harvey, Andrew Kaizer, Sai Mogali, Anurag Saxena, Swapneel       
 2045    Sheth, Nitin Singh, and Zhao Zhao provided critical "proof of           
 2046    concept" implementation experience that helped demonstrate the          
 2047    validity of the concepts described in this document.                    
 2048                                                                            
 2049    Pawel Kowalik and Mario Loffredo provided significant text              
 2050    contributions that led to welcome improvements in several sections of   
 2051    this document.  Their contributions are greatly appreciated.            
 2052                                                                            
 2053 Author's Address                                                           
 2054                                                                            
 2055    Scott Hollenbeck                                                        
 2056    Verisign Labs                                                           
 2057    12061 Bluemont Way                                                      
 2058    Reston, VA 20190                                                        
 2059    United States of America                                                
 2060    Email: shollenbeck@verisign.com                                         
 2061    URI:   https://www.verisignlabs.com/                                    
 2062                                                                            

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.