- gtld-tech - lists.icann.org

A-label and U-label mixing - RDAP query
by Gustavo Lozano April 19, 2016

April 19, 2016

Hello colleagues, Apologies for crossposting. During the public comments period of the "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars", https://www.icann.org/public-comments/rdap-profile-2015-12-03-en, the following comment was received: "Section 1.4.1 of the Operational Profile is inconsistent with the guidance given in RFC 7482 regarding processing of RDAP queries containing a mixture of IDN A-labels and U-labels. Per RFC 7482, ³IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels². This requirement is not only inconsistent with RFC 7482, it is also counter to the consensus of the IETF community regarding appropriate processing of IDN queries. " Another comment on the same path says: "Allowing A-labels and U-labels will be particularly unworkable for right to left languages unless the RDAP server introduces arbitrary restrictions. It is important to remember that RDAP is intended for machine-to-machine communication. Since RFC 7482 is very clear on this guidance (do not mix the two) any software client that generates this sort of query is broken. With the relative youth of the RDAP standard there is unlikely to be a large install base of software clients with said broken implementation. If ICANN is aware of a software client that has incorrectly implemented the RDAP standard and is now generating queries which combine A-labels and U-labels then ICANN should take its concerns to the IETF where such challenges are considered as part of any implementation discussion. Enshrining bad practice within the Operational Profile will result in needless future changes to the technology or additional service restrictions." The comment is related to the following section of the gTLD RDAP profile: "1.4.1 The RDAP server MUST support Internationalized Domain Name (IDN) RDAP lookup queries using A-label or U-label format [RFC 5890] for domain name and name server objects. The RDAP server MUST accept a mixture of the two (i.e. A-label and U-label format) in the same RDAP lookup query². The purpose of this message is to obtain feedback from this community regarding this issue. We believe that the following text from RFC 7482 is a requirement for the RDAP client: "IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels.". RFC7482 provides an example of why a server may receive a mixture of A-labels and U-labels in the query: "It is possible for an RDAP client to assemble a query string from multiple independent data sources. Such a client might not be able to perform conversions between A-labels and U-labels." RFC7482 gives two options to the server: "An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match lookup. In such cases, the response to be returned to the query source may not match the input from the query source. Alternatively, the server MAY refuse to process the query". We believe that the reasoning in RFC 7482 is sufficient to require gTLD RDAP servers to accept and process a query that mixes A-labels and U-labels. Question for this community: is the behavior specified in the gTLD RDAP Profile (I.e. requiring processing of queries that mixes A-labels and U-labels) consistent with RFC 7482? Your feedback is appreciated. Regards, Gustavo

4 4

ICANN 55 TechDay Agenda
by Dr Eberhard W Lisse March 6, 2016

March 6, 2016

Please find enclosed the currently final agenda. We had a cancellation this morning but fortunately we found someone prepared and ready. It'll be in the Oliveraie hall. greetings, el

1 0

Progress Report for the Verisign Labs Experiment with Federated Authentication for RDAP
by Hollenbeck, Scott Feb. 29, 2016

Feb. 29, 2016

Thank you to everyone who has taken part in the Verisign Labs experiment with federated authentication for RDAP. This is a summary of the things we've found through the end of February. Here's a link to my original description of the experiment: http://mm.icann.org/pipermail/gtld-tech/2016-February/000703.html 1. Back in January I sent a cross-area review request to the IETF OAuth mailing list: https://mailarchive.ietf.org/arch/msg/oauth/ir4Yu1U8_oM3l52j-difKKn3u8A One person volunteered to take a look. I'm still waiting for their feedback. 2. We found one issue with the OpenID Connect specification. The auth_time claim element of the ID Token is described as "a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC". We've found one implementation that represents this value as an integer, another that represents it as a float, and the two do not interoperate. We've opened issues in the GitHub repositories for both projects, but there's been no discussion. In the mean time we've patched the code we're running to make things work. 3. We found a few issues with our software implementation of RDAP, but nothing due to issues with the specifications. 3.1 We've had to fix response codes to note the difference between 404 (not found) and 501 (not implemented) responses. 3.2 Our first implementation of core RDAP omitted search functionality. We now have it implemented per RFC 7482. More interestingly, we've done some experimentation with more complex search patterns. I'll provide a more detailed description of our findings in another message at some point in the future. 4. We've integrated two identity providers in addition to the Google Gmail and Microsoft Hotmail providers described in my original note. Verisign Labs has developed an identity provider that allows us to make and test software changes (such as support for new claims) quickly as easily. We've also added support for an identity provider developed by CZ.NIC. CZ.NIC has been very helpful with debugging the interoperability issue described in point #2 above (thanks, Jaromír). We're still looking for people to both try the service as end users and/or participate in the experiment as RDAP servers operators or as identity providers. Please contact me directly for details. Scott

1 0

RDAP session in Marrakech
by Francisco Arias Feb. 25, 2016

Feb. 25, 2016

Dear colleagues, We are having a RDAP session in Marrakech on Monday, 7 March from 13:30 to 14:45 UTC. We plan to host a discussion on the open issues. The session page is at https://meetings.icann.org/en/marrakech55/schedule/mon-rdap-implementation There is going to be remote participation if you cannot make it to the meeting in person. We’d appreciate your participation. Regards, -- Francisco P.S. The session was moved from Thursday, in case you had that in your agenda.

4 6

Re: [gtld-tech] RDAP session in Marrakech
by Michele Neylon - Blacknight Feb. 25, 2016

Feb. 25, 2016

That time slot is right up against the Registrars’ meeting with law enforcement, as well as the CCWG Engagement session, so it’ll be very hard for any registrars to attend Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 24/02/2016, 23:46, "gtld-tech-bounces(a)icann.org on behalf of Francisco Arias" <gtld-tech-bounces(a)icann.org on behalf of francisco.arias(a)icann.org> wrote: >Dear colleagues, > >We are having a RDAP session in Marrakech on Monday, 7 March from 13:30 to 14:45 UTC. We plan to host a discussion on the open issues. The session page is at https://meetings.icann.org/en/marrakech55/schedule/mon-rdap-implementation > >There is going to be remote participation if you cannot make it to the meeting in person. We’d appreciate your participation. > >Regards, > >-- >Francisco > > >P.S. The session was moved from Thursday, in case you had that in your agenda.

1 0

Re: [gtld-tech] Draft gTLD RDAP profile in public comment
by Francisco Arias Feb. 12, 2016

Feb. 12, 2016

Dear Colleagues, Please note that the comment period has been extended to 31 January (https://www.icann.org/public-comments/rdap-profile-2015-12-03-en) Regards, -- Francisco On 12/4/15, 10:35 AM, "gtld-tech-bounces(a)icann.org on behalf of Francisco Arias" <gtld-tech-bounces(a)icann.org on behalf of francisco.arias(a)icann.org> wrote: >Dear colleagues, > >I wanted to let you know that the draft gTLD RDAP profile is now in public >comment at >https://www.icann.org/public-comments/rdap-profile-2015-12-03-en Your >input would be more than welcome. If you like to discuss in this list, we >will also take input received here into consideration. The public comment >period ends at 23:59 on 18-Jan-2016 UTC. > >The version that is for public comment takes into consideration the input >that we received from you in the list and during the in-person >discussions. Thank you for that. As you may remember there were a few open >items from those discussions, I’ll send a separate emails to explain what >we did regarding those in the current draft. > >In case it is of any help, I’ve attached a Word redline of the version we >published for public comment (v12) vs the version we shared in the list in >September (v06). > >Regards, > >-- >Francisco. >

1 2

Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server Content
by Francisco Arias Feb. 9, 2016

Feb. 9, 2016

Hi Scott, In all the cross-posting, it seems you may have left out the list where people have currently in scope doing something about this https://community.icann.org/display/gTLDRDS/Next-Generation+gTLD+Registrati… Regards, -- Francisco On 1/29/16, 5:34 AM, "weirds on behalf of Hollenbeck, Scott" <weirds-bounces(a)ietf.org on behalf of shollenbeck(a)verisign.com> wrote: >(cross-posting to multiple lists - sorry if that's inconvenient) > >So I saw a tweet from Gavin Brown (@GavinBrown) that describes how one particular search engine has indexed the RDAP server of a gTLD registry operator: > >https://twitter.com/GavinBrown/status/692718904058191872 > >This is all the more reason to work on a client authentication specification that includes support for varying responses based on client identity and authorization. I've been working on such a specification and welcome feedback on the approach: > >https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ > >It also begs the question of the need for a BCP describing operational practices for server operators. There are ways for web servers to influence or restrict crawler behavior, but what's appropriate in this context? > >Scott > >_______________________________________________ >weirds mailing list >weirds(a)ietf.org >https://www.ietf.org/mailman/listinfo/weirds

11 29

Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
by Hollenbeck, Scott Feb. 8, 2016

Feb. 8, 2016

Francisco, about a month ago I sent this message to this list: http://mm.icann.org/pipermail/gtld-tech/2016-January/000577.html You asked a few clarifying questions, which I answered. My last reply sent on 13 January: http://mm.icann.org/pipermail/gtld-tech/2016-January/000592.html I never did receive an answer to my original question: "Will those that do not be able to defer implementation until the needed "agreement provision, waiver, or Consensus Policy" terms are in place?" ? Scott

4 4

Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server Content
by Hollenbeck, Scott Feb. 8, 2016

Feb. 8, 2016

> -----Original Message----- > From: Francisco Arias [mailto:francisco.arias@icann.org] > Sent: Friday, February 05, 2016 3:53 PM > To: Hollenbeck, Scott; gtld-tech(a)icann.org > Subject: Re: [gtld-tech] [weirds] Search Engines Indexing RDAP Server > Content > > On 2/3/16, 9:40 AM, "gtld-tech-bounces(a)icann.org on behalf of > Hollenbeck, Scott" <gtld-tech-bounces(a)icann.org on behalf of > shollenbeck(a)verisign.com> wrote: > > > > >As I've said before, I want to deploy RDAP in a way that addresses the > issues we have with WHOIS. Functional equivalence provides no > significant benefit. > > Just to be clear, differentiated access is not the only benefit you get > from RDAP. I can think of at least the below benefits: > > 1. Internationalization support for registration data > 2. Standardized query, response, and error messages > 3. Standardized extensibility > 4. Supports private access to data (i.e., over HTTPS) > 5. Bootstrapping mechanism to easily find the authoritative server > for a given query > 6. Standardized redirection/reference mechanism (e.g., from a thin > registry to a registrar) > 7. Flexibility to support various policies All true, and not all to be realized "soon" given the multiple paths we're on. The current profile proposal says nothing about support for internationalized registration data. The bootstrapping mechanism doesn't work *at all* for entity queries. Thin-to-thick redirection won't be needed if/when thin registries become thick registries. Two of these (i18n and thick/thin) are still very much bound to ongoing policy work. As things are currently proposed we would get very little beyond benefits associated with HTTP and JSON-encoding. Scott

1 0

Verisign Labs Experimental Implementation of RDAP with Federated Authentication
by Hollenbeck, Scott Feb. 3, 2016

Feb. 3, 2016

I'd like to invite the members of this list to participate in an experiment that's focused on evaluating how well RDAP can be implemented with support for federated authentication using OpenID Connect. The details of the protocol specification and implementation approach are described in an Internet-Draft that I'm developing: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ The I-D might be a little too much detail for someone who just wants to try out the service, though. The easiest way to participate is to use a web browser pointed here: https://rdap.verisignlabs.com/ Please read the Internet-Draft if you're not interested in using a web browser. It describes the proposed protocol parameters and interactions with non-browser clients. Our web interface can be used to submit RDAP queries for domains, name servers, and entities registered in the .cc and .tv ccTLDs. The web form contains two elements: 1) a drop-down menu that allows you to select the type of object you wish to look up, and 2) the name of the object you wish to look up, such as "nic.tv" (with no quotes). You'll see two command buttons on the form. The "Don't Authenticate" button will submit an RDAP query without client authentication. The "Authenticate" button will start the process of submitting an authenticated RDAP query by prompting you to enter an OpenID identifier. We currently accept identifiers issued by Google (in the form of Gmail addresses) and Microsoft (in the form of Hotmail addresses). "Don't Authenticate" will return an RDAP response that contains very limited information to demonstrate how the amount of returned information can be controlled based on client identity and authorization. Successful client authentication using "Authenticate" will return more, but still not complete, information. We plan to add support for additional Identity Providers that will be authorized to return full information in the future as the experiment evolves. I'm especially interested in working with implementers who may be interested in setting up an Identity Provider and participating in the experiment. I've set up an email address that you can use to communicate with the development team. Please send questions and/or feedback to rdap-exp(a)verisign.com. The experiment's terms of use can be found here: https://rdap.verisignlabs.com/termsofuse The experiment will run until June 3, 2016. We will evaluate the results at that time and we will decide if the experiment will be extended or come to an end. We reserve the right to end the experiment at any time before then. Thank you, and please feel free to contact me directly with any questions. Scott

1 0