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

Wed Jul 20 09:24:37 UTC 2016

Hi Andrew,

my concern with re-using the mechaisms offered by http(s) is that to my 
knowledge it does not support differentiated or tiered access. So once 
you have access to a certain level of information, the protocol does not 
care what you use that access for.

Say I am a Turkish "law enforcement official" (whatever that means in 
these days) and have access to certain data fields because we decided 
that this is the level of access given to law enforcement. I can now 
access this level of information for anything. So we need not only 
authentication, but also protection from abuse of such authenticated 
users.  We need granulatity to be able to not only to say that user A 
has access to information level B, but also ensure that this information 
can only be requested for purpose C and prevent any access to the same 
information for abusive use D.

If for example law enforcement has the ability to access certain 
information based on a court order, we would have to ensure that this 
access level can only be used if such a court order is present, 
otherwise how to shoield users from abuse of the access we grant by policy?

I hope we will get to ask these questions further down the road and find 
a workable solution to them. In the meantime, I just wanted to note that 
authentication is not the solution, but only a step on the way towards 
the solution. The solution must be broader.

Best,
Volker

> 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
>

-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: vgreimann at key-systems.net

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP
www.keydrive.lu

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.