Re: Registry lock - two-factor or intervention

Hi all, 

At DNS Belgium we are also planning to implement a Registry Lock for .be, so I am definitely interested in developing a common standard. 

Given the limited interest (by registrants and/or registrars ?) seen at other registries, we plan to start with a mechamism that requires little development for the registry and 
little to no development effort for the registrars. 

We recently discussed several options with our Registrar Forum and this is what we came up with for an initial version: 

* a registry lock on a domain name can only be requested by the sponsoring registrar and only via the web interface and will not be visible nor updatable via EPP 
* the adminsitrative part (signing agreements, passing around contact details, etc) will be handled manually (exact procedures are still work-in-progress) 
* the registrant chooses who should be contacted when registrar requests to unlock the domain name 
=> IMO this offers the most flexibility: a registrant can choose to let his registrar handle the whole process or he can choose to be involved in the unlocking process himself 
* once the administrative part is handled, someone at the registry flags the registration as 'registry locked' 
=> no updates possible to linked registrant nor to the host attributes (NS and A records) of the domain name nor to the DS records (to be investigated if we would allow emergency key roll-overs) 
* the registrar requests (via the web interface) to unlock a domain name 
=> the registry seeks confirmation using the previously specified contact details. Upon confirmation: registry unlocks the domain name (TBD: indefinitely or for a limited time) 
* price: to be decided 

We don't foresee a two-factor authentication mechanism, although one could consider the pre-specified phonenumber as something you have. 
(We do however plan to add two-factor authentication to the registrar extranet, covering all possible transaction types not just those related to registry lock.) 

A further simplification (to speed up the roll-out) could be to handle lock and unlock requests entirely via the customer support system (and not via the registrar extranet). 

In a later phase (when the feature has enough success) we will consider to facilitate lock and unlock requests via EPP and to send EPP poll messages to notify the registrar when the lock or unlock has been approved. All of this of course preferably using a standardized EPP extension. 

Best regards, 

Maarten Bosteels 
Head of Development 
DNS Belgium 
+32 16 28 49 70 
www.dnsbelgium.be 

----- Original Message -----

| From: "Antoin Verschuren" <[email protected]>
| To: "Michele Neylon - Blacknight" <[email protected]>
| Cc: "<[email protected]>" <[email protected]>
| Sent: Thursday, 19 September, 2013 2:34:55 PM
| Subject: Re: [provreg] Registry lock - two-factor or intervention

| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1

| Op 19-09-13 11:22, Michele Neylon - Blacknight schreef:

| > This is not the general case, so your statement is biased.
| >
| >> So is your reaction :)

| Touche. :-).
| Just wanted to state that ICANN gTLD's are not the only norm. This is
| an IETF mailinglist. The IETF create standards, not ICANN contracts.

| > The role of the registrar is to offload administrative burden of
| > the registry, the registrar acts as an administrative agent for
| > the registrant.
| >
| >> Wow! That's actually incredibly offensive to registrars.

| Perhaps I'm just not a native speaker, and did not find a better term
| than burden, where I meant distribute administrative tasks to market
| players that are far better in communicating with end-customers.

| >> So any time there are *any* issues with *any* domains of any kind
| >> I can just send all the registrants, users and $random 3rd
| >> parties directly to the registry?

| I think it's the misunderstanding of the term "registrar" that has led
| and still leads to these strong statements.
| There are indeed a lot of entities that act as registrar in one of
| their roles that do a lot more than just that. They also act as
| dns-operator as a service to their customer, offer legal services, do
| website hosting, are a CA, or offer much more service to their
| customer, and do that well.
| But these extra services are not part of the pure registrar role in
| the model, as there are entities that act as registrar that do not
| offer these services, and it's important to clearly separate these
| roles when we need to come up with a clear model to base assumptions on.
| These entities are service providers, and one of their roles is acting
| as a registrar for those of their customers that are registrants.
| (They may have other customers that are not registrants). Registrar
| refers to the role, not to the entity.
| By administrative agent, I mean a registrar is responsible for all
| administrative, legal and financial communication and transactions
| between registrant and registry regarding the registration of a
| domain. The registrar represents the registry towards the registrant,
| and represents the registrant towards the registry.

| - --
| Antoin Verschuren

| Technical Policy Advisor SIDN
| Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

| P: +31 26 3525500 M: +31 6 23368970
| Mailto: [email protected]
| XMPP: [email protected]
| HTTP://www.sidn.nl/
| -----BEGIN PGP SIGNATURE-----
| Version: GnuPG v1.4.11 (GNU/Linux)

| iQEcBAEBAgAGBQJSOu9vAAoJEDqHrM883AgneqcH/3L3prtNQxfn1YwPb4pCCUs0
| 2v57k6bOlhvZKEPk0wDN6YzG/DkyAH8y6E5yqGuUp6esi2r3PH/hitdJ1HnxdDo7
| 0CKCUci9QFnGu3cwn/tBivm9e2VJ9ExOD0TwNGuVLEhNKmjX+IyN4viE17m6obzw
| rz0c/1fIYZYmoKfCSrVd1FchG0aWb9c49lY3VKQMItdkRBjogjz5U9SAezpVyCsU
| BcD0HXwGlwqrnlGi6JGUHzz3PH3LXXSXVxf7gLWHOL7yF5ocK6p5XRH0gCS01ipB
| +8z3ombUQ7qoF4ymjAQDLSITrSHlRtXObxMkFE9xbsue/tzBzPidA9bhjvIq+Rw=
| =X4fI
| -----END PGP SIGNATURE-----
| _______________________________________________
| provreg mailing list
| [email protected]
| https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg