Authorizing specific usages such as warrants or credit checks
Hello, I briefly previously in an e-mail that there was no way to handle warrants or other court orders via RDAP. Someone on the recent WG call said that this was covered in RDAP. I had a quick look through 4 RDAP RFC's (RFC 7480, RFC 7481, RFC 7482, and RFC 7483) and didn't see anything that seemed to match. Warrant Example =============== For a warrant, ideally the RDS would support a system like that which we have in place in every other part of the universe today. That is, if a court or some other authorized legal authority (this varies widely per jurisdiction, I know) issues a statement approving a search, then someone can be forced to turn over information. So, if the police get a warrant they can go to the company where you bought airline tickets and find out when and where you traveled. I think we all agree that this makes sense, although of course the details can be delightfully complicated. What I do not see in RDAP is any way for a registry or registrar to be served a warrant or other equivalent document. It IS possible for the police to have authorization to view private data, but I don't see any way for them to ONLY have authorization for this data if it is approved by a court on a case-by-case basis. I may have missed this! Please point me in the right direction so I can have a look at how RDAP proposes handling this. :) Credit Checks ============= Another use case that we discussed is possibly similar. In that case some agency was doing some sort of checks to make sure that a given applicant was going to be using a domain for an approved purpose. In order to do this they use the current WHOIS data to do some sanity checks and look for various patterns that signal fraud. In my mind, this *could* be similar because it also involves getting access to private data only for a specific lookup. So, rather than granting a for-profit, private company access to all private data of everyone with a domain name, the person who wants a service can authorize a sort of credit/background check. This check could indeed give complete access to all records for that person, but in principle need not give the company access to all data. Again, I don't think that any of the current technologies support this, but I am hardly an expert in authentication or authorization systems, so this sort of thing might be supported today. Happy Thoughts ============== I saw/heard on the call the tension between WG members who lean towards minimal access (privacy advocates, human rights representatives, dirty hippies like myself) and WG members who lean towards insuring responsible use of systems and helping authorities prevent crime and other abuse (LEA representatives, IP lawyers, and so on). We didn't delve into it too deeply but I am looking forward to a policy that balances everyones needs. I was heartened that everyone was polite and constructive! Cheers, -- Shane
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org] On Behalf Of Shane Kerr Sent: Tuesday, August 02, 2016 3:57 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Authorizing specific usages such as warrants or credit checks
Hello,
I briefly previously in an e-mail that there was no way to handle warrants or other court orders via RDAP. Someone on the recent WG call said that this was covered in RDAP.
I had a quick look through 4 RDAP RFC's (RFC 7480, RFC 7481, RFC 7482, and RFC 7483) and didn't see anything that seemed to match.
Warrant Example =============== For a warrant, ideally the RDS would support a system like that which we have in place in every other part of the universe today. That is, if a court or some other authorized legal authority (this varies widely per jurisdiction, I know) issues a statement approving a search, then someone can be forced to turn over information.
So, if the police get a warrant they can go to the company where you bought airline tickets and find out when and where you traveled. I think we all agree that this makes sense, although of course the details can be delightfully complicated.
What I do not see in RDAP is any way for a registry or registrar to be served a warrant or other equivalent document. It IS possible for the police to have authorization to view private data, but I don't see any way for them to ONLY have authorization for this data if it is approved by a court on a case-by-case basis.
I may have missed this! Please point me in the right direction so I can have a look at how RDAP proposes handling this. :)
Core RDAP can't do this, but I've described a possible approach in an Internet-Draft: https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/ Look at Section 3.1.4.1, "Claims", and Section 6. It is possible to associate information with an end-user identity that can be shared with a server operator as part of an RDAP query. I haven't thought through the warrant situation completely, but let's imagine that it's possible to create a "warrant" claim. A law enforcement identity provider would associate a warrant claim to an end user identity, and the end user would share that claim with the replying party (the RDAP server) as part of an authenticated RDAP query. The server operator receives the claim(s) and makes authorization and access control decisions based on the identity and associated claims, returning whatever information is dictated by some "respond to warrant request" policy. There would probably need to be an out-of-band mechanism to serve the warrant that allows the server operator to validate a warrant claim. Scott
The same would apply for court orders obtained by rights holders regarding hidden customer information as well? Am 03.08.2016 um 14:31 schrieb Hollenbeck, Scott:
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg- bounces@icann.org] On Behalf Of Shane Kerr Sent: Tuesday, August 02, 2016 3:57 PM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Authorizing specific usages such as warrants or credit checks
Hello,
I briefly previously in an e-mail that there was no way to handle warrants or other court orders via RDAP. Someone on the recent WG call said that this was covered in RDAP.
I had a quick look through 4 RDAP RFC's (RFC 7480, RFC 7481, RFC 7482, and RFC 7483) and didn't see anything that seemed to match.
Warrant Example =============== For a warrant, ideally the RDS would support a system like that which we have in place in every other part of the universe today. That is, if a court or some other authorized legal authority (this varies widely per jurisdiction, I know) issues a statement approving a search, then someone can be forced to turn over information.
So, if the police get a warrant they can go to the company where you bought airline tickets and find out when and where you traveled. I think we all agree that this makes sense, although of course the details can be delightfully complicated.
What I do not see in RDAP is any way for a registry or registrar to be served a warrant or other equivalent document. It IS possible for the police to have authorization to view private data, but I don't see any way for them to ONLY have authorization for this data if it is approved by a court on a case-by-case basis.
I may have missed this! Please point me in the right direction so I can have a look at how RDAP proposes handling this. :) Core RDAP can't do this, but I've described a possible approach in an Internet-Draft:
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/
Look at Section 3.1.4.1, "Claims", and Section 6. It is possible to associate information with an end-user identity that can be shared with a server operator as part of an RDAP query. I haven't thought through the warrant situation completely, but let's imagine that it's possible to create a "warrant" claim. A law enforcement identity provider would associate a warrant claim to an end user identity, and the end user would share that claim with the replying party (the RDAP server) as part of an authenticated RDAP query. The server operator receives the claim(s) and makes authorization and access control decisions based on the identity and associated claims, returning whatever information is dictated by some "respond to warrant request" policy. There would probably need to be an out-of-band mechanism to serve the warrant that allows the server operator to validate a warrant claim.
Scott _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- 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@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@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.
On Wed, Aug 03, 2016 at 02:49:24PM +0200, Volker Greimann wrote:
The same would apply for court orders obtained by rights holders regarding hidden customer information as well?
Why not? The nice thing about Scott's draft is that, once you have this infrastructure, you get all those other features automatically. (This very idea was built into the approach pursued by the RIRs when they first started prototyping what became RDAP. Murray Kucherawy and I included notions like this in the first BoF advocacy for the WEIRDS WG that created RDAP, but I think it got whittled out of the charter in an attempt to drive to completion.) Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Credit Checks ============= In my mind, this *could* be similar because it also involves getting access to private data only for a specific lookup. So, rather than granting a for-profit, private company access to all private data of everyone with a domain name, the person who wants a service can authorize a sort of credit/background check. This check could indeed give complete access to all records for that person, but in principle need not give the company access to all data.
This is perhaps "backwards". Someone doing a "check" doesn't need to be _provided_ with personal data, as opposed to them _providing_ the data and getting a Yes/No response. A bank doesn't hand out the name & address of their account holders (as a general rule) They do respond to financial queries from 3rd-parties when asked along the lines of _name_ of _address_ says they have an account with you, _details_, attached is their approval of this enquiry, can you confirm ? Plus those queries are logged, and available for the account holder to audit/get details of. Rob -- Rob Golding rob.golding@astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR * domains * hosting * vps * servers * cloud * backups *
participants (5)
-
Andrew Sullivan -
Hollenbeck, Scott -
Rob Golding -
Shane Kerr -
Volker Greimann