Re: Registry lock - two-factor or intervention

Hi,

At CIRA we are also currently developing our business requirements and initial design of a Registry Lock service for .CA.  The question and discussion of a common epp extension / implementation approach not only for Registry Lock, but for the exposure of value-add or additional services per domain is something we are very interested in as well.

From where we currently are in our analysis, I am also in agreement that is seems logical to leverage epp for the setting of the lock itself.

There does, however, look to be an intrinsic requirement for a separately authenticated step prior to the rar being allowed to set the server flags via epp - and also prior to removal of the flags to allow for domain modification.

The question of whether these separately authenticated steps should be automated (epp or other) or manual (person to person) is something we are quite focused on at the moment and would definitely invite feedback or real-world experience on either approach.

As I mentioned above, we are also looking at how best to generally expose services that can be applied / added onto domains - to rar's.  These services could be Registry Lock, or any other value added service.   If there any extensions out there that someone has put together for this purpose I would be very interested to learn more about them as well.

In either case, we are interested in participating in the discussion and development of standardized approaches as well.

Thanks,
Stu

STU OLMSTEAD-WILCOX. Development Manager
Canadian Internet Registration Authority (CIRA)
(613) 237-5335 x265

From: [email protected] [mailto:[email protected]] On Behalf Of MICHAEL YOUNG
Sent: September-20-13 11:28 AM
To: Patrik Fältström
Cc: Maarten Bosteels; provreg
Subject: Re: [provreg] Registry lock - two-factor or intervention

If you have an automated system, why implementing something else than EPP?

Different reasons in different use cases, but really non EPP APIs (I think anyways) come into play when you are dealing with arm's length associated actions or decisions that in turn trigger a core EPP call.

For one example, some registries are heading towards stronger identity verification, where the registrant must be examined by a third party (to both the registry and registrar) before a registration is allowed to be finalized.  I use the word finalized carefully, because while that verification occurs, one could using a pending create or one could also combine a typical registration with all the server prohibited statuses applied.  When the verification process is successfully done, a core EPP command then results in the registration going to a "regular" state - whatever that happens to be for that particular registry.

Registry Lock really is a product that happens to entail more than just firing a core EPP command, there are elements of identity verification, two party involvement, etc, all of which really happen outside the registry.  The final result of all that activity is that a core EPP command is triggered to apply Server prohibited statuses or to remove them.  During most of the lead up process, I have no real need or desire to talk with an EPP server, just at the end of the decision making.

The actual functionality of an EPP Server is relatively straight-forward, when you think of comparative large systems, which a really good thing in an infrastructure system.  I think if we are to hope to successfully standardize extensions, we should be critical of which elements of proposed extension use cases really need to involve an EPP server, and which are better served as an external system.

That said, don't get me wrong, I'm all for standardization whenever we can achieve it.


MICHAEL YOUNG
[email protected]<mailto:[email protected]>

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