cgoldfeder 75d9268ecd Resolve an old TODO by doing nothing ... The RFCs are ambiguous. 5733 (contacts): 3.2.4. EPP <transfer> Command ...the <transfer> command MUST contain a <contact:transfer> element that identifies the contact namespace. The <contact:transfer> element contains the following child elements: ... - A <contact:authInfo> element that contains authorization information associated with the contact object. However, the xsd explicitly marks it as optional: <complexType name="authIDType"> <sequence> <element name="id" type="eppcom:clIDType"/> <element name="authInfo" type="contact:authInfoType" minOccurs="0"/> </sequence> </complexType> The language in 5731 (domains) is [] The only example given in both is for a transfer request, which is the one flow that obviously requires the authInfo. We had decided that for transfer approve and reject, which are done by the losing client, requiring the authInfo is silly because it's available to that registrar from an <info> and there's no extra security in having them present it (although if they do present it we validate it). The question about cancel was whether the gaining client, which had to present the authInfo in the original transfer request, needs it again for cancel. I can't come up with any reason this would be beneficial, and I'm making the decision: authInfo is not required on transfer cancel. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=133168739		2016-09-19 11:46:14 -04:00
..
com/google	Fix up license headers and Python linting	2016-08-02 19:16:42 -04:00
google/registry	Resolve an old TODO by doing nothing	2016-09-19 11:46:14 -04:00