- gtld-tech - lists.icann.org

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

Search Engines Indexing RDAP Server Content
by Hollenbeck, Scott Feb. 3, 2016

Feb. 3, 2016

(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

7 7