User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-Id: <82ef0b63-13cb-403b-886d-de66f7086890@www.fastmail.com>
In-Reply-To: <436A323C-AD02-4FFE-A182-B9376AFF3783@verisign.com>
References: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch>
 <35BAECA0-9B4A-4C1F-9EEF-BA9C4BE2E325@verisign.com>
 <4bbb8a33bee54a8797fc75a1cf532899@switch.ch>
 <185b57cd-984c-4167-8e62-fc37dcf46fdf@www.fastmail.com>
 <436A323C-AD02-4FFE-A182-B9376AFF3783@verisign.com>
Date: Fri, 20 Dec 2019 12:13:45 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Fbkuiv7hgm-j8c2L9oNFT_4FHSY>
Subject: Re: [regext] 
 =?utf-8?q?How_to_handle_Domain_Info_Command_with_empty_?=
 =?utf-8?q?authinfo/pw_tag_in_command=3F?=
Precedence: list



On Fri, Dec 20, 2019, at 11:47, Gould, James wrote:
> The EPP RFC 5731 does support the explicit <domain:null> element to 
> remove the authorization information, so there is an explicit mechanism 
> available in the RFC to set the authorization information to NULL (the 
> undefined value).

Yes, I know, and this exactly outlines why an absent node is not the same
thing as a node with an empty value.

Said differently,
<domain:authInfo><domain:pw/></domain:authInfo> is an existing authInfo whose
value is the empty string
where
<domain:authInfo><domain:null/></domain:authInfo> means an undefined authInfo
(so could be any value).

> Where there is no explicit element in the EPP RFCs to indicate not 
> setting or unsetting the authorization information, the empty 
> authorization information can be used for this purpose in a defined 
> practice, such as draft-gould-regext-secure-authinfo-transfer. 

As you know, I am not convinced this is the best course for the future,
nor that it really fits the working group. But that is just me.

> Having discussion and agreement around the authorization information 
> practice would help with the inconsistencies that you outlined in your 
> follow-on message, and help increase the authorization information 
> security. 

I remain in another side: other solutions, instead of passwords, should be found.
Continuing to use passwords when other (better) solutions exist is not an effort
I find useful.

-- 
  Patrick Mevzek
  pm@dotandco.com