search

icann / rdap-conformance-tool

New Library to validate RDAP Conformance
15 stars 7 forks source link

wrong validation of "identifier" in --use-rdap-profile-february-2019 #14

Closed aldot closed 2 years ago

aldot commented 2 years ago

Hi!

When using the --use-rdap-profile-february-2019 to check compliance with https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf , the type of "identifier" is not specified to be a JSON-string or a JSON-number. The type is not specified at all.

Yet, at the moment, the tool erroneously complains if an "identifier" like publicIds, handle or eventActor is a JSON-number.

The 15feb19 spec requires to implement RFC7483. In RFC7483, the "identifier" is specified to be: https://datatracker.ietf.org/doc/html/rfc7483#section-4.8

o  identifier -- a public identifier of the type denoted by "type"

This was later clarified in RFC9083 ( https://datatracker.ietf.org/doc/html/rfc9083#section-4.8 ) to be a string:

*  identifier -- a string denoting a public identifier of the type
      related to "type"

But the option --use-rdap-profile-february-2019 specifically asks for checking compliance with the 15feb19 profile, with RFC7483.

So, what is the underlying type of the IANA GURID, a.k.a the IANA registrar-ids? If you look at https://www.iana.org/assignments/registrar-ids/registrar-ids.rng you can see that it is specified as a positiveInteger:

            <element name="value"><data type="positiveInteger"/></element>
            <element name="name"><text/></element>
            <element name="status"><text/></element>

And if you look at the corresponding https://www.icann.org/en/accredited-registrars?filter-letter=a&sort-direction=asc&sort-param=name&page=1 you will notice that the column title is IANA Number (and not IANA String for that matter).

Hence, in accordance with RFC7483 and the IANA schema for registrar-ids, it is perfectly valid to return publicIds, handle (a GURID), and eventActor as JSON-number if --use-rdap-profile-february-2019 is in effect. Please adjust you conformance-tool accordingly, so that it accepts either a JSON-string or a JSON-number for "identifier" typed values as per RFC7483. thanks,

e-alvarez commented 2 years ago

Hello @aldot, Thank you for your comments, we have reviewed the RDAP specifications referenced and believe that the members mentioned handle, publicIds/#/identifier and eventActor are in fact expected as JSON strings.

Looking at RFC 7483, section 1.2 (Data Model) states that RDAP responses are formed by data structures, object classes or arrays of objects, and "simple data types conveyed in JSON strings". The RDAP conformance tool will expect a JSON string accordingly unless a different data type is explicitly specified in the member definition. Furthermore, the handle member is explicitly defined as as a JSON character string in section 3 (Common data types) and again as a string in each of the object class definition sections, for example section 5.1 (The Entity Object Class).

For the publicIds data structure defined in section 4.8, the identifier member is conveyed in a JSON string in the examples illustrating the use of type "IANA Registrar ID", as well as in appendix A.2 (Registrar) which includes an example specifically representing a registrar entity.

Regarding the eventActor member we found no indication that this member is ever expected in the form of a number instead of a JSON string as shown in all examples in the specification where this member appears. Could you provide more information as to how/when the eventActor member must support different data types in addition to JSON string?

This is also aligned with the updates included in RFC 9083 which our understanding is that the new version was rephrased to improve clarity, and not as a change to the requirements discussed here.