Steve Crocker (author of #RFC 1) presents the Jake project. It's about access to registration data (protocols like #RDAP). This access raises a lot of issues (invalid data, privacy, spam, etc).
The idea seems to attach metadata to requests, data and responses. For instance, requestors have to state their credentials ("gold" access to important orgs like police and IP lawyers) and the purpose.
With the metadata attached to both requestors (who, why, what) and data, #RDAP servers could apply a matrix of authorization. (US police may access personal data for US registrants, I presume.)
The picture seems quite complicated, I have doubt that such thing could ever be deployed.
There is even the possibility of labelling collected data with things like "verified".
I discover there was a proposal for a general "Undo" command in #EPP… https://datatracker.ietf.org/doc/html/draft-brown-epp-reverse
Ulrich Wisser on regitry lock (locking a domain against changes, by forcing a manual action, activate it if your domain is critical to your activity)
The idea is to allow automatic *locking* (obviously not - yet - unlocking) through #EPP. May be also locking with automatic unlocking after some time.
(Remember: there is no end-to-end security, registrant to registry)
Oh, and if you don't know how a domain name registry works, you can start with this simple article https://www.afnic.fr/en/observatory-and-resources/expert-papers/what-happens-when-you-register-a-domain-name/
First question is of course about the transition. Everyone dislikes jCard/vCard but it is already implemented. Should we do it again?
Carlos Ganan on #RDAP performance (measuring the response time). The actual measurement lasted one month, from ten vantage points , to every RDAP server known.
Average RTT 1 second, with some outliers taking MINUTES to respond.
The RIR were the fastest, the registrars the slowest.
Highly dependant on the vantage point: probably no anycast on the server?
Now, the demo. "An error occurred'" Reloading the page and it worked but then query timeouted.
Jaromir Talir about #RegeID, an identity solution.
Based on eIADS (european framework for mutual recognition of digital identities). France's #FranceConnect will join soon.
For domain name registry, it could mean mandatory checking of identity to get a domain name (like in Estonia and Denmark).
Also, the future NIS 2 european directive plans to mandate these identity checks to have a domain name.
People raise concerns about mandatory identity checking for domain names. What if the government does not like you? (Short answer: eIDAS is just a framework, each country can set its own rules, and making the check mandatory or not)
Identity again. Werner Staub suggests to use email addresses of domain name registrants to join with identity services.
Nice domain for examples https://botsin.space/@DNSresolver/106375989049156954 (yes, it is what its name says)
But you cannot use any email address for that. It may be misleading (firstname.lastname@example.org) or leak personal data. So, it has to be an email address in a known domain, such as their id.sport.
Jothan Frakes on the Public Suffix List https://publicsuffix.org/ (finding the responsible domain, for instance foo.eu.org and bar.eu.org are not under the same administration). A volunteer project, not official. Widely used in browsers and many other things.
I even used it in one of my projects, the #Gemini crawler #Lupa https://framagit.org/bortzmeyer/lupa/-/commit/5aed4e365c5ccdc451d4103d3af3ea013225c017
The Public Suffix List rejects additions for domains in "alternative roots". People often react violently to this rejection.
The Public Suffix List is important: unlike what many people think, not every registration domain is a TLD.
The speaker insists: DON'T USE REGEXPS TO VALIDATE IF SOMETHING IS A TLD, OR IF IT IS A REGISTRATION DOMAIN.
Use of the Public Suffix List, and refreshing of its content, is a choice by the developer of an application, they do what they want, nothing is mandatory.
Some warnings for developers: do not rely on this list for real security.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!