[gnso-rds-pdp-wg] An important technical consideration about nature of the service (was Re: The overflowing list )

[Stephanie Perrin]

Thanks for that explanation Andrew!  (and I think I understand it, so 
that means you were exceptionally clear, I am a pretty good litmus test 
on tech talk since I am v non-technical).  This would really help with 
policy distinctions, as you say, and would mean that whatever happens 
with the Msoft decision, we can respond effectively.  Here is the first 
legislative response, which I must say was pretty quick.....more 
reaction will come swiftly we are told. 
https://www.lawfareblog.com/us-government-presents-draft-legislation-cross-border-data-requests.

cheers Stephanie Perrin


On 2016-07-16 2:09, Andrew Sullivan wrote:
> On Sat, Jul 16, 2016 at 01:12:30AM -0400, Stephanie Perrin wrote:
>> images of video tapes that have not been used in 15 years).  To be clear, we
>> need to talk about control of data elements.
> I agree (these are the same as "datum" in the questions I asked -- the
> individual elements of a set of data).
>
>> If I understand RDAP correctly, it would permit duly authorized data access
>> from anywhere, to elements that could be scattered.
> In principle, it could.
>
>> current data mining techniques.  The problem, as I see it, and I beg to be
>> corrected if I am wrong, is how do we manage a remote authorization scheme
>> to individual data elements, if indeed some data is held by the registrar,
>> some by the registry, and some (outside ICANN's remit, but an answer to LEA
>> demands) by the ISP?
> This is a great question.
>
> RDAP itself does not actually answer this, because RDAP just uses
> http(s).  The idea in the design was exactly that we could then re-use
> any authentication and authorization mechanisms that http(s) offers,
> and so if a new one was invented we'd get that benefit too.  (All good
> designs proceed from a basic laziness: don't re-invent something if
> you can just re-use something others have already got working.)
>
> The initial answer is just basic http authentication, and that would
> require each to-be-authenticated individual to get such authentication
> logins with everyone providing RDS, which would be awful.  So that's
> not actually the plan.
>
> Scott Hollenbeck, who is participating in this WG, has a nice draft
> that'll probably see some discussion at the IETF meeting in Berlin
> next week
> (https://tools.ietf.org/html/draft-hollenbeck-regext-rdap-openid-00#ref-OIDCC).
> It's a way of using RDAP with OpenID Connect, which is a federated
> authentication and authorization mechanism.  (It's really intended to
> provide an identity layer on top of OAuth.)  I'm waving away some
> details and distinctions, but this is the sort of thing that you use
> when you "sign in using Facebook" or "sign in using Google" or
> whatever.
>
> Using this sort of thing, you could have one credential that various
> RDS operators would accept.  Once you're authenticated, the credential
> would continue to work across referrals from one RDS to another (using
> RDAP), so that the _user_ experience is of a single monolithic system
> while the _technical_ operation is of a distributed system.  Moreover,
> individual RDS operators could use different policies based on local
> law to provide the kinds of responses appropriate to the legal
> conditions under which they operate.  This would of course mean that
> registrations in some jurisdictions might release more information
> than others, but that's consistent with the legal obligations and
> norms that arise from having multiple jurisdictions in the first place.
>
> Now, there are important details in the operation of any such
> federated identity system, and questions we'd have to ask about how
> the vetting process for identification would work and whether we'd
> need multiple additional tokens (for instance, an identity presented
> with an id of a subpoena might have different qualifications than an
> identity without such a subpoena).  That's all policy that would need
> to be developed, but it would all be policy that could avoid
> specifying details of technical implementations, which would be an
> improvement over historic whois policy :)
>
> If any of that is not clear, or if we need to develop some more
> detailed tutorial-like info for participants here to read offline or
> something, I hope people will let me know.  We really do now have the
> technlogy to enable quite fine policy distinctions, and I think that
> basic fact is useful for our future deliberations.
>
> Best regards,
>
> A
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160716/8c7e3f75/attachment.html>