[regext] Re: Thoughts on AuthCodeSEC

[Victor Zhou <[e-mail]>]

Christian,

Yes the goal is the receiver will need to be known at the time
AuthCode(SEC) is submitted to the registry.

Assuming you are talking about Model B
In the Model B, the receiver is Gaining Registrar. (As opposed to in Model
A the receiver is the Gaining Registrant.)

In Model B,
1. The registrant retrieves the public key identifier (PKI) of Gaining
Registrar(GR)
-- note: it can be retrieved by getting it from published by GR or its
website
2. The registrant asks its Losing Registrar to generate a AuthCodeSEC by
providing a PKI of GR.
3. Instead of randomly generating shared passwords, Losing Registrar signs
a RFC-AuthCodeSEC signature including PKI of GR.
LR gives AuthCodeSEC to the Registrant
4. The registrant gives AuthCodeSEC to the GR
-- note: Here we are skipping backward compatibility step: LR also submits
AuthCodeSEC to registry to be stored because In Model B, the registry is
required to support RFC-AuthCodeSEC
5. GR submits AuthCodeSEC to Registry with extInfo
6. The registry verifies the AuthCodeSEC and approves the transfer
-- note: skipping details about Pending Transfer, LR time to rejection etc


Victor,
CEO & founder of Namefi <http://namefi.io>, tokenizing domain names for
trading, DeFi and future Internet. https://namefi.io



On Mon, Nov 4, 2024 at 6:37 AM Christian Simmen <[e-mail]>
wrote:

> Hi Victor,
>
> If I got you right the gaining registrar needs to be known at the time
> the AuthCode is submitted to the registry. AFAIK there are some use
> cases out there where this is not applicable. Can you describe how
> AuthCodeSEC would work in this case?
>
> Thanks in advance
> Christian
>