[TSG-Access-RD] Text Added

Thu Feb 21 00:47:05 UTC 2019

I’m sending the below on behalf of Göran:

Hi,

ICANN have no possibility as an non-for-profit organization to take that role as the financial consequences would be unlimited. The alternative would be to dramatically raise the funding from contracted parties to cover this type of expense. Personally I do not believe that any contracted party would be interested either as the control system that has to be set up would probably infringe any contracted party’s ability to use data. This data is often used for other purposes than WHOIS.

Furthermore, the idea behind this group is to come up with a technical solution that diminishes the contracted parties legal responsibilities so to add this to the document is actually in contradiction to what the group is set up to achieve.

Regards

Göran Marby
CEO&President ICANN

From: TSG-Access-RD <tsg-access-rd-bounces at icann.org> On Behalf Of Ram Mohan
Sent: Wednesday, February 20, 2019 3:20 PM
To: Jody Kolker <jkolker at godaddy.com>; tsg-access-rd at icann.org
Subject: Re: [TSG-Access-RD] Text Added

Hi Jody,
We have to see if that is a valid assumption on all sides. It’s not clear to me that ICANN has acquiesced with such an assumption so far, and from what I can see, it is still being debated on the policy side.

At best, we should send this onwards to ICANN to see if they agree.

-Ram

---------------------------------------------------------------------------------
Ram Mohan
(o) +1.215.706.5700 x103  (m) +1.215.431.0958  (f) +1.215.706.5701
rmohan at afilias.info<mailto:rmohan at afilias.info> | Skype: gliderpilot30 | Twitter @rmohan123
---------------------------------------------------------------------------------

From: Jody Kolker <jkolker at godaddy.com<mailto:jkolker at godaddy.com>>
Sent: Wednesday, February 20, 2019 5:59 PM
To: tsg-access-rd at icann.org<mailto:tsg-access-rd at icann.org>
Subject: Re: [TSG-Access-RD] Text Added

I would like this assumption to be added:

I believe this assumption should be added:

ICANN will enter into an agreement indemnifying Contracted Parties if fines are levied due to the release of non-public data through this implementation.

Is there any reason why this assumption cannot be added to the document?

Thanks,
Jody Kolker

From: TSG-Access-RD <tsg-access-rd-bounces at icann.org<mailto:tsg-access-rd-bounces at icann.org>> On Behalf Of Jody Kolker
Sent: Tuesday, February 19, 2019 10:31 AM
To: Andrew Newton <andy at hxr.us<mailto:andy at hxr.us>>; Jorge Cano <jcano at nic.mx<mailto:jcano at nic.mx>>
Cc: tsg-access-rd at icann.org<mailto:tsg-access-rd at icann.org>
Subject: Re: [TSG-Access-RD] Text Added

Hi Andy,

Regarding this text:

<<

While this model relieves ICANN of a significant and potentially unworkable burden of vetting and credentialing requestors, it also delegates control of data exposure policy to third parties, a complication that may be overkill given the number of policies necessary for proper data governance.
>>

Is it worthwhile to mention that CP’s will most likely not be comfortable with allowing anyone but ICANN controlling data exposure policy?  Again, one of the assumptions that still hasn’t been added to the document is that ICANN will enter into an agreement indemnifying CPs if fines are levied due to the release of non-public data.

Thanks,
Jody Kolker

From: TSG-Access-RD <tsg-access-rd-bounces at icann.org<mailto:tsg-access-rd-bounces at icann.org>> On Behalf Of Andrew Newton
Sent: Tuesday, February 19, 2019 9:33 AM
To: Jorge Cano <jcano at nic.mx<mailto:jcano at nic.mx>>
Cc: tsg-access-rd at icann.org<mailto:tsg-access-rd at icann.org>
Subject: Re: [TSG-Access-RD] Text Added

On Mon, Feb 18, 2019 at 10:31 PM Jorge Cano <jcano at nic.mx<mailto:jcano at nic.mx>> wrote:
Dear all,

I read the document and pretty much agree with it, but have a couple of questions.

1. In the Actor Models section, at the mapping of the organizational entities to the actors, the point 5 defines the ICANN RDAP Proxy as a Relying Party. Shouldn’t the ICANN RDAP Proxy be defined as a Resource Server?

From RFC 6749 “The OAuth 2.0 Authorization Framework” (https://www.rfc-editor.org/rfc/rfc6749.txt [rfc-editor.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6749.txt&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YHDWysfNgG9kn4Mk3Oyp9ccgD3bKUf2w88Lvdup8hZw&m=92VZl_TGshSlLWTFz4ZxI2DC4qsbcmBW2eTg3_ZWGYc&s=WpQkaDPf1dBsRK8asKBbE0q7w-MBkXILWi_7pP-YlIM&e=>)
Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

And from “OpenID Connect Core 1.0 Specification” (https://openid.net/specs/openid-connect-core-1_0.html [openid.net]<https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_specs_openid-2Dconnect-2Dcore-2D1-5F0.html&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YHDWysfNgG9kn4Mk3Oyp9ccgD3bKUf2w88Lvdup8hZw&m=92VZl_TGshSlLWTFz4ZxI2DC4qsbcmBW2eTg3_ZWGYc&s=zW3_TLGZ6p-dMcB6nlVIgG8SkduT0JCZ6eLLHRvng1c&e=>)
Relying Party (RP): OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider.

Isn’t this last definition better suited for the ICANN RDAP Access Service?

Jorge,

I believe you are correct. I'll make the change. Thanks for double checking this.

-andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20190221/e64ebcf6/attachment-0001.html>