[TSG-Access-RD] Text Added

[Jody Kolker]

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<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)
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/61badb87/attachment-0001.html>