--- 1/draft-ietf-regext-rdap-openid-11.txt 2022-03-23 10:13:15.104523769 -0700 +++ 2/draft-ietf-regext-rdap-openid-12.txt 2022-03-23 10:13:15.164525273 -0700 @@ -1,19 +1,19 @@ REGEXT Working Group S. Hollenbeck Internet-Draft Verisign Labs -Intended status: Standards Track 24 February 2022 -Expires: 28 August 2022 +Intended status: Standards Track 23 March 2022 +Expires: 24 September 2022 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect - draft-ietf-regext-rdap-openid-11 + draft-ietf-regext-rdap-openid-12 Abstract The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 28 August 2022. + This Internet-Draft will expire on 24 September 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights @@ -74,45 +74,45 @@ 3.1.4. Specialized Claims for RDAP . . . . . . . . . . . . . 9 3.1.4.1. Stated Purpose . . . . . . . . . . . . . . . . . 9 3.1.4.2. Do Not Track . . . . . . . . . . . . . . . . . . 10 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 10 4.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Session . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Device Info . . . . . . . . . . . . . . . . . . . . . 12 4.2. Client Login . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. Clients with Limited User Interfaces . . . . . . . . 15 4.2.1.1. UI-constrained Client Login . . . . . . . . . . . 15 - 4.2.1.2. UI-constrained Client Login Polling . . . . . . . 16 + 4.2.1.2. UI-constrained Client Login Polling . . . . . . . 17 4.3. Session Status . . . . . . . . . . . . . . . . . . . . . 17 4.4. Session Refresh . . . . . . . . . . . . . . . . . . . . . 18 4.5. Client Logout . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Parameter Processing . . . . . . . . . . . . . . . . . . 21 5. Token Exchange . . . . . . . . . . . . . . . . . . . . . . . 21 6. RDAP Query Processing . . . . . . . . . . . . . . . . . . . . 21 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 22 8.2. JSON Web Token Claims Registry . . . . . . . . . . . . . 23 8.3. RDAP Query Purpose Registry . . . . . . . . . . . . . . . 23 - 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 - 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 26 - 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 26 - 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 27 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 10.1. Authentication and Access Control . . . . . . . . . . . 28 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 - 12.2. Informative References . . . . . . . . . . . . . . . . . 30 - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 + 9.1. Editor Implementation . . . . . . . . . . . . . . . . . . 27 + 9.2. Verisign Labs . . . . . . . . . . . . . . . . . . . . . . 27 + 9.3. Viagenie . . . . . . . . . . . . . . . . . . . . . . . . 28 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 10.1. Authentication and Access Control . . . . . . . . . . . 29 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 12.2. Informative References . . . . . . . . . . . . . . . . . 31 + Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP) [RFC7230]. @@ -469,28 +469,28 @@ 4.1. Data Structures This specification describes two new data structures that are used to return information to a client: a "session" data structure that contains information that describes an established session, and a "deviceInfo" data structure that contains information that describes an active attempt to establish a session on a UI-constrained device. 4.1.1. Session - The "session" data structure is an array that contains two sub- - arrays: + The "session" data structure is an object that contains two sub- + objects: - 1. A "userClaims" array that contains the set of claims associated - with the End-User's identity, with each claim represented as a - name-value pair in string format. The set of possible values is + 1. A "userClaims" object that contains the set of claims associated + with the End-User's identity as used/requested by the RDAP server + to make access control decisions. The set of possible values is determined by OP policy. - 2. A "sessionInfo" array that contains two name-value pairs: + 2. A "sessionInfo" object that contains two members: a. "tokenExpiration": an integer value that represents the number of seconds from the current time for which the Access Token remains valid, and b. "tokenRefresh": A boolean value that indicates if the OP supports refresh tokens. As described in RFC 6749 [RFC6749], support for refresh tokens is OPTIONAL. An example of a "session" data structure: "session": { @@ -518,22 +518,22 @@ The flow described in Section 3.1.3 requires an End-User to interact with a server using a user interface that can process HTTP. This will not work well in situations where the client is automated or an End-User is using a command line user interface such as curl (http://curl.haxx.se/) or wget (https://www.gnu.org/software/wget/). This limitation can be addressed using a web browser on a second device. The information that needs to be entered using the web browser is contained in the "deviceInfo" data structure. - The "deviceInfo" data structure is an array that contains three name- - value pairs: + The "deviceInfo" data structure is an object that contains three + members: 1. "verification_url": the URL that the End-User needs to visit using the web browser, 2. "user_code": the string value that the End-User needs to enter on the form presented in the web browser, and 3. "expires_in": an integer value that represents the number of seconds after which the opportunity to visit the URL and enter the user_code will expire. An example of a "deviceInfo" data structure: @@ -660,32 +660,38 @@ adding a query component to an RDAP request URI using the syntax described in Section 3.4 of RFC 3986 [RFC3986], or by including an HTTP authorization header for the Basic authentication scheme as described in RFC 7617 [RFC7617]. If the RDAP server supports a local Authorization Server, the End-User identifier MAY be omitted. Clients can use either of these methods. Servers MUST support both methods. The query used to request client authentication is represented as an OPTIONAL "key=value" pair using a key value of "id" and a value - component that contains the client identifier issued by an OP. An - example using wget for client identifier "user.idp.example": + component that contains the client identifier issued by an OP. + + An example using wget for client identifier "user.idp.example": + + wget -qO- --keep-session-cookies --save-cookies\ + https://example.com/rdap/session/device?id=user.idp.example + Figure 5 - wget -qO- --keep-session-cookies --save- - cookies\https://example.com/rdap/session/device?id=user.idp.example The authorization header for the Basic authentication scheme contains a Base64-encoded representation of the client identifier issued by an - OP. No password is provided. An example using curl and an - authorization header: + OP. No password is provided. - curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\-c - cookies.txt https://example.com/rdap/session/device + An example using curl and an authorization header: + + curl -H "Authorization: Bearer dXNlci5pZHAuZXhhbXBsZQ=="\ + -c cookies.txt https://example.com/rdap/session/device + + Figure 6 The response to this request MUST use the response structures specified in RFC 9083 [RFC9083]. In addition, the response MUST include an indication of the requested operation's success or failure in the "notices" data structure (including the client identifier), and, if successful, a "deviceInfo" data structure. An example of a "session/device" response: { @@ -696,45 +702,51 @@ "notices": { "title": "Device Login Result", "description": [ "Login succeeded", "user.idp.example" ] }, "deviceInfo": { "verification_url": "https://www.example.com/device", "user_code": "NJJQ-GJFC", - "expires_in": "1800" + "expires_in": 1800 } } - Figure 5 + Figure 7 4.2.1.2. UI-constrained Client Login Polling After successful processing of the "session/device" request, the client MUST send a "session/devicepoll" request to the RDAP server to continue the login process. This request performs the polling function described in RFC 8628 [RFC8628], allowing the RDAP server to wait for the End-User to enter the information returned from the "session/device" request using the interface on their second device. After the End-User has completed that process, or if the process fails or times out, the OP will respond to the polling requests with - an indication of success or failure. An example using wget: + an indication of success or failure. - wget -qO- --load-cookies - cookies.txt\https://example.com/rdap/session/devicepoll + An example using wget: + + wget -qO- --load-cookies cookies.txt\ + https://example.com/rdap/session/devicepoll + + Figure 8 An example using curl: curl -b cookies.txt https://example.com/rdap/session/devicepoll + Figure 9 + The response to this request MUST use the response structures described in Section 4.2. RDAP query processing can continue normally on the UI-constrained device once the "login" process has been completed. 4.3. Session Status Clients MAY send a query to an RDAP server to determine the status of an existing login session using a "session/status" path segment. An example "session/status" request: @@ -774,21 +786,21 @@ "purpose": "domainNameControl", "dnt": false }, "sessionInfo": { "tokenExpiration": 3490, "tokenRefresh": true } } } - Figure 6 + Figure 10 4.4. Session Refresh Clients MAY send a request to an RDAP server to refresh, or extend, an existing login session using a "session/refresh" path segment. The RDAP server MAY attempt to refresh the access token associated with the current session as part of extending the session for a period of time determined by the RDAP server. As described in RFC 6749 [RFC6749], OP support for refresh tokens is OPTIONAL. An RDAP server MUST determine if the OP supports token refresh and process @@ -833,21 +845,21 @@ "purpose": "domainNameControl", "dnt": false }, "sessionInfo": { "tokenExpiration": 3599, "tokenRefresh": true } } } - Figure 7 + Figure 11 4.5. Client Logout Clients MAY send a request to an RDAP server to terminate an existing login session. Termination of a session is requested using a "session/logout" path segment. Access and refresh tokens can be revoked during the "session/logout" process as described in RFC 7009 [RFC7009] if supported by the OP (token revocation endpoint support is OPTIONAL per RFC 8414 [RFC8414]). If supported, this feature SHOULD be used to ensure that the tokens are not mistakenly @@ -879,21 +891,21 @@ "title": "Logout Result", "description": [ "Logout succeeded", "user.idp.example", "Provider logout failed: Not supported by provider.", "Token revocation successful." ] } } - Figure 8 + Figure 12 In the absence of a "logout" request, an RDAP session MUST be terminated by the RDAP server after a server-defined period of time. The server should also take appropriate steps to ensure that the tokens associated with the terminated session cannot be reused. This SHOULD include revoking the tokens or logging out from the OP if either operation is supported by the OP. 4.6. Parameter Processing @@ -956,166 +968,218 @@ described in Section 8.1. Example rdapConformance structure with extension specified: "rdapConformance" : [ "rdap_level_0", "rdap_openidc_remote_level_0" ] - Figure 9 + Figure 13 8. IANA Considerations 8.1. RDAP Extensions Registry IANA is requested to register the following values in the RDAP Extensions Registry: - * Extension identifier: rdap_openidc_remote_level_0 - * Registry operator: Any - * Published specification: This document. - * Contact: IESG - * Intended usage: This extension describes a federated + Extension identifier: rdap_openidc_remote_level_0 + Registry operator: Any + Published specification: This document. + Contact: IESG + Intended usage: This extension describes a federated authentication method for RDAP using OAuth 2.0, OpenID Connect, and a remote Authorization Server. - * Extension identifier: rdap_openidc_local_level_0 - * Registry operator: Any - * Published specification: This document. - * Contact: IESG - * Intended usage: This extension describes a federated + Extension identifier: rdap_openidc_local_level_0 + Registry operator: Any + Published specification: This document. + Contact: IESG + Intended usage: This extension describes a federated authentication method for RDAP using OAuth 2.0, OpenID Connect, and a local Authorization Server. 8.2. JSON Web Token Claims Registry IANA is requested to register the following values in the JSON Web Token Claims Registry: - * Claim Name: "purpose" - * Claim Description: This claim describes the stated purpose for + Claim Name: "purpose" + Claim Description: This claim describes the stated purpose for submitting a request to access a protected RDAP resource. - * Change Controller: IESG - * Specification Document(s): Section 3.1.4.1 of this document. + Change Controller: IESG + Specification Document(s): Section 3.1.4.1 of this document. - * Claim Name: "dnt" - * Claim Description: This claim contains a JSON boolean literal that + Claim Name: "dnt" + Claim Description: This claim contains a JSON boolean literal that describes an End-User's "do not track" preference for identity tracking, logging, or recording when accessing a protected RDAP resource. - * Change Controller: IESG - * Specification Document(s): Section 3.1.4.2 of this document. + Change Controller: IESG + Specification Document(s): Section 3.1.4.2 of this document. 8.3. RDAP Query Purpose Registry IANA is requested to create a new protocol registry to manage RDAP - query purpose values. This registry should appear under its own - heading on IANA's protocol listings, using the same title as the name - of the registry. The information to be registered and the procedures - to be followed in populating the registry are described in + query purpose values. This registry should be named "Registration + Data Access Protocol (RDAP) Query Purpose Values" and should appear + under the "Registration Data Access Protocol (RDAP)" section of + IANA's protocol registries. The information to be registered and the + procedures to be followed in populating the registry are described in Section 3.1.4.1. - Name of registry: Registration Data Access Protocol (RDAP) Query - Purpose Values - - Section at http://www.iana.org/protocols: + Section at http://www.iana.org/protocols: Registration Data Access + Protocol (RDAP) - Registry Title: Registration Data Access Protocol (RDAP) Query + Name of registry: Registration Data Access Protocol (RDAP) Query Purpose Values - Registry Name: Registration Data Access Protocol (RDAP) Query Purpose - Values - Registration Procedure: Specification Required - Reference: This draft + Reference: This document Required information: See Section 3.1.4.1. Review process: "Specification Required" as described in RFC 5226 [RFC5226]. Size, format, and syntax of registry entries: See Section 3.1.4.1. Initial assignments and reservations: - -----BEGIN FORM----- Value: domainNameControl Description: Tasks - within the scope of this purpose include creating and managing and - monitoring a registrant's own domain name, including creating the - domain name, updating information about the domain name, transferring - the domain name, renewing the domain name, deleting the domain name, - maintaining a domain name portfolio, and detecting fraudulent use of - the Registrant's own contact information. -----END FORM----- + -----BEGIN FORM----- + + Value: domainNameControl + + Description: Tasks within the scope of this purpose include + creating and managing and monitoring a registrant's own domain + name, including creating the domain name, updating information + about the domain name, transferring the domain name, renewing the + domain name, deleting the domain name, maintaining a domain name + portfolio, and detecting fraudulent use of the Registrant's own + contact information. - -----BEGIN FORM----- Value: personalDataProtection Description: Tasks - within the scope of this purpose include identifying the accredited - privacy/proxy provider associated with a domain name and reporting - abuse, requesting reveal, or otherwise contacting the provider. -----END FORM----- - -----BEGIN FORM----- Value: technicalIssueResolution Description: - Tasks within the scope of this purpose include (but are not limited - to) working to resolve technical issues, including email delivery - issues, DNS resolution failures, and web site functional issues. + -----BEGIN FORM----- + + Value: personalDataProtection + + Description: Tasks within the scope of this purpose include + identifying the accredited privacy/proxy provider associated with + a domain name and reporting abuse, requesting reveal, or otherwise + contacting the provider. + -----END FORM----- - -----BEGIN FORM----- Value: domainNameCertification Description: - Tasks within the scope of this purpose include a Certification - Authority (CA) issuing an X.509 certificate to a subject identified - by a domain name. -----END FORM----- + -----BEGIN FORM----- - -----BEGIN FORM----- Value: individualInternetUse Description: Tasks - within the scope of this purpose include identifying the organization - using a domain name to instill consumer trust, or contacting that - organization to raise a customer complaint to them or file a - complaint about them. -----END FORM----- + Value: technicalIssueResolution + + Description: Tasks within the scope of this purpose include (but + are not limited to) working to resolve technical issues, including + email delivery issues, DNS resolution failures, and web site + functional issues. + + -----END FORM----- + + -----BEGIN FORM----- + + Value: domainNameCertification + + Description: Tasks within the scope of this purpose include a + Certification Authority (CA) issuing an X.509 certificate to a + subject identified by a domain name. + + -----END FORM----- + + -----BEGIN FORM----- + + Value: individualInternetUse + + Description: Tasks within the scope of this purpose include + identifying the organization using a domain name to instill + consumer trust, or contacting that organization to raise a + customer complaint to them or file a complaint about them. + + -----END FORM----- + + -----BEGIN FORM----- + + Value: businessDomainNamePurchaseOrSale - -----BEGIN FORM----- Value: businessDomainNamePurchaseOrSale Description: Tasks within the scope of this purpose include making - purchase queries about a domain name, acquiring a domain name from a - registrant, and enabling due diligence research. -----END FORM----- - -----BEGIN FORM----- Value: academicPublicInterestDNSRResearch - Description: Tasks within the scope of this purpose include academic - public interest research studies about domain names published in the - registration data service, including public information about the - registrant and designated contacts, the domain name's history and - status, and domain names registered by a given registrant (reverse - query). -----END FORM----- + purchase queries about a domain name, acquiring a domain name from + a registrant, and enabling due diligence research. - -----BEGIN FORM----- Value: legalActions Description: Tasks within - the scope of this purpose include investigating possible fraudulent - use of a registrant's name or address by other domain names, - investigating possible trademark infringement, contacting a - registrant/licensee's legal representative prior to taking legal - action and then taking a legal action if the concern is not - satisfactorily addressed. -----END FORM----- + -----END FORM----- + + -----BEGIN FORM----- + + Value: academicPublicInterestDNSRResearch + + Description: Tasks within the scope of this purpose include + academic public interest research studies about domain names + published in the registration data service, including public + information about the registrant and designated contacts, the + domain name's history and status, and domain names registered by a + given registrant (reverse query). + + -----END FORM----- + + -----BEGIN FORM----- + + Value: legalActions + + Description: Tasks within the scope of this purpose include + investigating possible fraudulent use of a registrant's name or + address by other domain names, investigating possible trademark + infringement, contacting a registrant/licensee's legal + representative prior to taking legal action and then taking a + legal action if the concern is not satisfactorily addressed. + + -----END FORM----- + -----BEGIN FORM----- + + Value: regulatoryAndContractEnforcement - -----BEGIN FORM----- Value: regulatoryAndContractEnforcement Description: Tasks within the scope of this purpose include tax - authority investigation of businesses with online presence, Uniform - Dispute Resolution Policy (UDRP) investigation, contractual - compliance investigation, and registration data escrow audits. + authority investigation of businesses with online presence, + Uniform Dispute Resolution Policy (UDRP) investigation, + contractual compliance investigation, and registration data escrow + audits. + -----END FORM----- - -----BEGIN FORM----- Value: - criminalInvestigationAndDNSAbuseMitigation Description: Tasks within - the scope of this purpose include reporting abuse to someone who can - investigate and address that abuse, or contacting entities associated - with a domain name during an offline criminal investigation. + -----BEGIN FORM----- + + Value: criminalInvestigationAndDNSAbuseMitigation + + Description: Tasks within the scope of this purpose include + reporting abuse to someone who can investigate and address that + abuse, or contacting entities associated with a domain name during + an offline criminal investigation. + -----END FORM----- - -----BEGIN FORM----- Value: dnsTransparency Description: Tasks within - the scope of this purpose involve querying the registration data made - public by registrants to satisfy a wide variety of use cases around - informing the general public. -----END FORM----- + -----BEGIN FORM----- + + Value: dnsTransparency + + Description: Tasks within the scope of this purpose involve + querying the registration data made public by registrants to + satisfy a wide variety of use cases around informing the general + public. + + -----END FORM----- 9. Implementation Status NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 [RFC7942]. The description of implementations in this section is @@ -1135,82 +1199,82 @@ It is up to the individual working groups to use this information as they see fit". Version -09 of this specification introduced changes that are incompatible with earlier implementations. Implementations that are consistent with this specification will be added as they are identified. 9.1. Editor Implementation - * Location: https://procuratus.net/rdap/ - * Description: This implementation is a functionally-limited RDAP + Location: https://procuratus.net/rdap/ + Description: This implementation is a functionally-limited RDAP server that supports only the path segments described in this specification. It uses the "jumbojett/OpenID-Connect-PHP" library found on GitHub, which appears to no longer be under active development. The library was modified to add support for the device authorization grant. Session variable management is still a little buggy. Supported OPs include Google (Gmail) and Yahoo. - * Level of Maturity: This is a "proof of concept" research + Level of Maturity: This is a "proof of concept" research implementation. - * Coverage: This implementation includes all of the features + Coverage: This implementation includes all of the features described in this specification. - * Version compatibility: Version -11 of this specification. - * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com + Version compatibility: Version -11+ of this specification. + Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 9.2. Verisign Labs - * Responsible Organization: Verisign Labs - * Location: https://rdap.verisignlabs.com/ - * Description: This implementation includes support for domain + Responsible Organization: Verisign Labs + Location: https://rdap.verisignlabs.com/ + Description: This implementation includes support for domain registry RDAP queries using live data from the .cc and .tv country code top-level domains and the .career generic top-level domain. Three access levels are provided based on the authenticated identity of the client: 1. Unauthenticated: Limited information is returned in response to queries from unauthenticated clients. 2. Basic: Clients who authenticate using a publicly available identity provider like Google Gmail or Microsoft Hotmail will receive all of the information available to an unauthenticated client plus additional registration metadata, but no personally identifiable information associated with entities. 3. Advanced: Clients who authenticate using a more restrictive identity provider will receive all of the information available to a Basic client plus whatever information the server operator deems appropriate for a fully authorized client. Currently supported identity providers include those developed by Verisign Labs (https://testprovider.rdap.verisignlabs.com/) and CZ.NIC (https://www.mojeid.cz/). - * Level of Maturity: This is a "proof of concept" research + Level of Maturity: This is a "proof of concept" research implementation. - * Coverage: This implementation includes all of the features + Coverage: This implementation includes all of the features described in this specification. - * Version compatibility: Version -07 of this specification. - * Contact Information: Scott Hollenbeck, shollenbeck@verisign.com + Version compatibility: Version -07 of this specification. + Contact Information: Scott Hollenbeck, shollenbeck@verisign.com 9.3. Viagenie - * Responsible Organization: Viagenie - * Location: https://auth.viagenie.ca - * Description: This implementation is an OpenID identity provider + Responsible Organization: Viagenie + Location: https://auth.viagenie.ca + Description: This implementation is an OpenID identity provider enabling users and registries to connect to the federation. It also includes a barebone RDAP client and RDAP server in order to test the authentication framework. Various level of purposes are available for testing. - * Level of Maturity: This is a "proof of concept" research + Level of Maturity: This is a "proof of concept" research implementation. - * Coverage: This implementation includes most features described in + Coverage: This implementation includes most features described in this specification as an identity provider. - * Version compatibility: Version -07 of this specification. - * Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca + Version compatibility: Version -07 of this specification. + Contact Information: Marc Blanchet, marc.blanchet@viagenie.ca 10. Security Considerations Security considerations for RDAP can be found in RFC 7481 [RFC7481]. Security considerations for OpenID Connect Core [OIDCC] and OAuth 2.0 [RFC6749] can be found in their reference specifications. OpenID Connect defines optional mechanisms for robust signing and encryption that can be used to provide data integrity and data confidentiality services as needed. @@ -1376,20 +1440,22 @@ text to Section 3.1.4.2 to note that "do not track" requires compliance with local regulations. 08: Rework of token management processing in Sections 4 and 5. 09: Updated RDAP specification references. Added text to describe both local and remote Authorization Server processing. Removed text that described passing of ID Tokens as query parameters. 10: Updated Section 3.1.3.1. Replaced token processing queries with "login", "session", and "logout" queries. 11: Replaced queries with "session/*" queries. Added description of "rdap" OAuth scope. Added implementation status information. + 12: Updated data structure descriptions. Updated Section 8. Minor + formatting changes due to a move to xml2rfc-v3 markup. Author's Address Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: shollenbeck@verisign.com URI: http://www.verisignlabs.com/