[TSG-Access-RD] Text Added

[Ram Mohan]

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 | Skype: gliderpilot30 | Twitter @rmohan123
---------------------------------------------------------------------------------



*From:* Jody Kolker <jkolker at godaddy.com>
*Sent:* Wednesday, February 20, 2019 5:59 PM
*To:* 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> *On Behalf Of *Jody
Kolker
*Sent:* Tuesday, February 19, 2019 10:31 AM
*To:* Andrew Newton <andy at hxr.us>; Jorge Cano <jcano at nic.mx>
*Cc:* 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> *On Behalf Of *Andrew
Newton
*Sent:* Tuesday, February 19, 2019 9:33 AM
*To:* Jorge Cano <jcano at nic.mx>
*Cc:* 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> 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)
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)
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/20190220/eb9dbd19/attachment.html>