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 <christian.sim...@gmx.de> 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 >
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
