This page provides information on our approach to using DNS-based verified credentials. Please check back here for the latest updates.

ICANN66 – Montreal, Canada (NOV-2019)

At ICANN66, InfoNetworks co-sponsored the INTA’s Innovations in Domain Name Safety. At the event, we demonstrated the benefits of our approach for Trusted Notifier programs. to address domain abuse. A copy of our presentation can be found here.

ICANN65 – Marrakech, Morocco (JUN-2019)

At ICANN65, we presented our approach and updated solution to the Expedited Policy Development Process (EPDP) Team, the Government Advisory Council (GAC), and the Intellectual Property Constituency (IPC) of the Generic Names Supporting Organization (GNSO). Links to ICANN’s recordings of these presentations are below:

A copy of the slides that we presented can be found here. The slides have been updated to include two Appendices: a detailed overview of refinements to our operational solution, and more background on the need for a UNIFORM disclosure access model.

ICANN64 – Kobe, Japan (MAR-2019)

At ICANN64, we provided demonstrations of our approach that highlighted several important features: (1) accreditation of Requestors and use of federated, verified credentials; (2) customizable “due process” rules for accessing (and using) non-public data; and (3) logging of requests and Requestor obligations if their request is challenged.

A one-page summary of the solution as discussed at ICANN64 may be downloaded here, and a more detailed overview of what was shown may be downloaded here.

We made some policy assumptions for the ICANN64 demo, but our operational solution may be easily adapted to changes in policy, and for additional requirements by Contracted Parties.

A “walk-thru” of our ICANN64 demo is below.

Accreditation of Requestors

The proposed approach enables a Requestor to use a digital identity that they already have, instead of obtaining new credentials specifically for accessing non-public registration data. A digital identity from any participating identity provider (IdP) may be used, so long as the identifying information for the Requestor has been sufficiently verified by that IdP as a trusted source. This is illustrated below:

The demo illustrates WIPO as verifying the qualifications of a Requestor to request non-public data for intellectual property purposes. We have illustrated accrediting an attorney, but there could also be accreditation for other IP purposes, such as by an IP owner on their own behalf, or by a domain owner / purchaser for a commercial transaction.

Please visit https://wipo.verifyip.info to try the accreditation process. Once you begin registration, please use the identifier “yza234-az.myidp.tld” and the email address “requestor@verifyip.info“. This identifier illustrates the use of DNS as a discovery mechanism for locating a user’s personal IdP. The solution is not limited to this approach, but the DNS may provided added value for digital identity, beyond name registration and management.

For the demo, the Requestor practices law in the United States and is a member of the Florida bar, with registration number of 000000.

When the information is submitted, the Requestor will receive a confirmation email that their information has been queued for review the verifying party (WIPO in this example). Below is a screenshot illustrating an open review ticket in the ticketing system used for the demo:

In addition to the specific information submitted by the Requestor, an agent for the verifying party would obtain the Requestor’s verified personal data from the Requestor’s personal IdP.

To try this, please visit https://whois.verifyip.org/yza234-az.myidp.tld. When you do, the WHOIS gateway uses this information to discover the Requestor’s IdP and will redirect you to the the Requestor’s personal IdP (located at https://us.data.verifyip.info). Once there, you would authenticate your WIPO agent credentials to view the Requestor’s personal data. Please enter the user name “demo-agent@wipo.int” and the password “wiporequest123“.

In the demo, the Requestor’s personal IdP stores the Requestor’s personal data in the United States, but the approach anticipates a user’s personal data residing in various jurisdictions. Using DNS as a discovery mechanism allows the WIPO agent to request the Requestor’s personal data in a manner similar to accessing non-public WHOIS data (described in the Request section below).

Note: Under the proposed approach, the verifying party does not need to store a copy of the Requestor’s personal data, but instead may rely on the IdP maintaining that information in escrow for the verifying party to use for their specified purpose. This is done with the Requestor’s consent, in accordance with the terms of their Requestor Agreement. This enables the verifying party to reduce its costs and risks that associated with protecting that information, yet still enables them to use the information as needed.

This same benefit will be available to Contracting Parties, who may adopt the same approach for Registrants and their domain registration contact.

The agent for the verifying party would then conduct the level of verification specified by policy. If everything is in order, the agent would then notify the Requestor’s IdP confirming the Requestor has been verified as a valid Requestor for the period of time specified by policy (e.g., one year), and this attribute is added to the Requestor’s profile with the IdP.

Note: This assumes that the confirmed verification is stored with the Requestor’s IdP, so that the when the Requestor seeks non-public data, they both authenticate themselves and their valid Requestor credentials through their own IdP.

To try the process of confirming verification of a Requestor, please visit https://wipo.verifyip.info/update. Please enter the Requestor’s identifier for their digital identity: “yza234-az” and select “Verify“. When you (as the WIPO agent) submit this information, it is confirmed with the Requestor’s IdP, and the Requestor’s digital identity may be used for requesting non-public registration data.

Note: A similar process may be used to manually revoke a Requestor’s authorization, such as pursuant to a decision under the dispute resolution process for challenging a Requestor’s qualifications and data requests.

Requesting Non-Public Registration Data

The proposed approach may be used with a centralized request process (e.g., through ICANN) or a decentralized process (e.g., through individual Contracting Parties). In either case, a verified Requestor’s digital identity credentials would be federated, so that the party managing access would rely on authentication of those credentials by the Requestor’s IdP (e.g., using an OAuth / OpenID Connect framework).

To try the request process, please visit https://whois.verifyip.org. Please use the domain name “illegalcontent.tld” for the request. For the demo, we have shown a simple, single domain search. However, our approach may also be used for bulk requests, for reverse WHOIS search, and for searches of pseudonymized WHOIS data (such as to determine patterns of activity) as determined by policy.

Please use the same Requestor identifier used for the accreditation process above: “yza234-az.myidp.tld“. The demo is hardcoded for an intellectual-property related request, but the solution may be adapted for other types of requests (which may have a different request process).

When you click “Begin,” the system will redirect you to the Requestor’s IdP by using the DNS based discovery process noted above. The solution is not limited to this approach, but it illustrates the added value for the DNS system for digital identity beyond name registration and management.

Below is an illustration of the request process:

After you are redirected to your (the Requestor’s) U.S. based IdP, you are prompted to authenticate yourself with the user name “requestor@verifyip.info” and the password “datarequest123“.

While the demo uses a standard log-in, the solution may employ multi-factor authentication and various forms of authentication; e.g. FIDO compliant solutions, digital certificates and PKI, etc.

The authentication framework used for the demo is OAuth / OpenID Connect (as recommended by the Technology Steering Group), though other federated authentication frameworks could be used.

Once you have authenticated as a valid Requestor, you are then redirected to the sample process for intellectual property related requests. The system prompts you to provide information to demonstrate the specified purpose for your request (e.g. establishing a legal claim related to intellectual property) and to chose the specific data fields needed for purpose. You then attest to the accuracy of the information provide, that you are acting in good faith, and that your use of the non-public information is subject to the established rules of use (including an ex post challenge process by impacted data subjects).

You then submit the request. If there are no additional “due process” rules for the data being requested, you will then be provided with the requested data. Certain data may, for example, be subject to an out-of-band review process (such as for certain legal persons based on the protected nature of their activity).

Request Logging and Requestor Obligations

The proposed approach also incorporates logging and a binding dispute resolution process to provide transparency and help ensure accountability for the use of personal data.

Requests written to an auditable log (with any exceptions by policy), which may be shared, public, or private by policy. An impacted data subjects may also be notified by policy. Personal data for all verified parties will be retained for appropriate designated retention periods.

Logs may be pseudonymized by policy with unmasking similar to request process. And, just as with the request process or registration data, the unmasking of Requestors, may also have core / optional unmasking rules by policy, may incorporate by purpose-based credentials, and may also include a purpose-based request flow. Such an unmasking process is illustrated below:

Notwithstanding the accreditation of Requestors and differentiated “due process” rules for requests, the proposed approach also incorporates binding ex post dispute resolution. This provides impacted data subjects a mechanism to challenge:

  • The validity of a Requestor’s qualifications / rule violations
  • Sufficiency to which a Requestor’s has demonstrated a specified purpose
  • Whether a Requestor has exceeded the allowed scope of use

To further provide accountability, bonding by Requestors or other financial safeguards may also be required by policy.