[Openid-specs-risc] RISC Agenda for today

Taborszky, Anton a.taborszky at telekom.de
Fri May 8 07:20:17 UTC 2015


I spent some time searching for EU directives on “Data Breach Notification Rule” and came across this document (http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp213_en.pdf) and this comment (https://privacyassociation.org/news/a/eu-data-breach-notification-rule-the-key-elements).
As far as I understand the directive the competent national authority is to be notified. The individual, user or, as used in the directive, the “data subject” is only to be notified
“When the personal data breach is likely to adversely affect the personal data or privacy of a data subject1, the data controller shall also notify the data subject of the breach without undue delay”.

What if we let the user decide on whether the account is to be linked to an account with another provider.
The screenshot is taken from my profile @ scrumalliance.org

Talk to you in a few hours
Anton
[cid:image001.png at 01D0896D.3D6EB350]

Von: Openid-specs-risc [mailto:openid-specs-risc-bounces at lists.openid.net] Im Auftrag von Nat Sakimura
Gesendet: Samstag, 2. Mai 2015 17:40
An: Adam Dawes
Cc: openid-specs-risc at lists.openid.net; Brad Hill; aatoc at googlegroups.com
Betreff: Re: [Openid-specs-risc] RISC Agenda for today

From the privacy regulation point of view, each region has its limits.
I am not a lawyer and the following is not a legal advice but just a general comment, but it may be a useful view. The privacy regulation situation may be better than you think.

In case of EU, we could justify the sharing of the data through the conditions of processing of EU Directive and the forthcoming regulation. There are handful of those conditions, but for our case, we could tap specifically into these:

  *   The processing is necessary:

     *   in relation to a contract which the individual has entered into; or
     *   because the individual has asked for something to be done so they can enter into a contract.

  *   The processing is in accordance with the “legitimate interests” condition.
The Processing is necessary -- It is probably reasonable to assume that the user and the relying party has entered into a relation that the user expects safeguarding of his account at the relying party. To fulfill it, if the relying party regards it is important to share that information with the email or identity provider, it may do so accordingly. The provider side is a little more tricky but as long as the provider has been notified by the relying party, and relying party was deemed trustworthy, then it would probably be reasonable to think that sharing the account status information with the said relying party is reasonably expected as necessary for executing the safeguarding expectation by the user.

Legitimate interest -- alternatively, we can flip and use legitimate interest as long as we can determine that the benefit that the services obtain is not unreasonable compared to the privacy impact to the user. In this case, we could say that it is a legitimate interest of the services and providers to safeguard the accounts and the negative privacy impact caused by it is minimal because we only share the "signal" etc.

In the United States, since the legal restrictions are sector specific, we may need to treat each sector accordingly. This can be a bit more tricky, but it could be done. This administration's thinking, as I read from the recent Privacy Bill of Rights proposal, the sharing of the information for the security related purpose is exempt from general restriction. So, we may want to leverage that.

In Japan, we are a bit out of luck in this respect, but we may be able to come up with something through the consultation to the data protection authority.

Cheers,

Nat @ Kuching, Malaysia

2015-05-02 15:55 GMT+09:00 Adam Dawes <adawes at google.com<mailto:adawes at google.com>>:
I think Brad and Nat's points are both spot on. I agree that this is harder to justify on a go-forward OAuth basis. But with a mass opt-in based on agreement (bi-lateral or trust framework), I'm far less certain I can persuade my organization to go there.

I was interested in Anton's comments here. He said he thought that this kind of arrangement would not fly in Germany. Anton, would like to hear if you have more specific thoughts about this. Do you think there is a way to make mass opt-in palatable?

I suspect the best I could hope for would be to have a big announcement that Google was joining a trust framework with N other companies to share account security data and the privacy protections require x, y, and z. I'll need to start doing some asking around but my gut tells me that still would be a pretty big ask.

On Fri, May 1, 2015 at 5:13 PM, Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>> wrote:
+1

Just a few points.

For the first tier, which I label as "mass enrollment", A trust framework where a trust framework operator and other participants get into contracts may work better from the scalability point of view. Mutual legal agreement quickly get us into N^2 agreement explosion whereas a trust framework only has N+1.

Also, we should not use the term "opt-in" in this case since we are enrolling the users by default.  we are enrolling the users with opt-out.

Nat

—
Mailbox<https://www.dropbox.com/mailbox> から送信


On Sat, May 2, 2015 at 8:36 AM, Brad Hill <hillbrad at gmail.com<mailto:hillbrad at gmail.com>> wrote:
Regarding today's discussion on establishing trust relationships and bootstrapping for already established accounts.  I would argue for a two-tiered approach.
One tier would be companies that execute mutual legal agreements and are able to opt-in users via their global ToS. This would likely require with an opt-out mechanism as deemed appropriate by each organization's legal counsel and appropriate to the markets they operate in, but this could be transparent to the other side of the relationship.  So long as company X and Y have a mutual agreement executed, all requests for account data would be whitelisted.  If X said "I have an account for user at Y", you'd believe them, and have contractual recourse if they were lying.

The second tier would require more explicit opt-in, like an OAuth flow, to connect the accounts, and because it would have direct user approval would not need any prearrangements between the entities holding the accounts on the user's behalf.

I think trying to force all existing accounts to go through an explicit consent flow is just too big of an obstacle to ever getting operational at a meaningful scale.  Maybe some large organizations in some jurisdictions would prefer or need to use the explicit opt-in flows exclusively, but having a streamlined flow where some large fraction of the top 10 or 100 global account providers can establish mutual trust to bootstrap the first 10e8 connections without an enormous amount of explicit point-to-point bookkeeping and user friction seems absolutely necessary for this to be meaningful in protecting users on any reasonable time scale.

If there are tradeoffs to be made in terms of the scope or fidelity of the sharing vs. the ability to automatically provision, I would urge we go as far as we can towards low-fidelity low-friction (while still providing a useful signal) for the same reason.

-Brad

On Fri, May 1, 2015 at 7:14 AM 'Adam Dawes' via Abuse and ATO Coordination <aatoc at googlegroups.com<mailto:aatoc at googlegroups.com>> wrote:

Agenda

·      IPR update

·      OASIS group STIX/TAXII next steps

·      PR release<https://docs.google.com/document/d/16QrQo5O1Afj4sZBZhJDHr9HxTtWERGHdle-0a4B6UT8/edit>

·      Weekly call times

·      Technical Discussion

     *   How do we operationalize trust relationships. Going forward, looking backward


Where: https://global.gotomeeting.com/join/764054389

Use your microphone and speakers (VoIP) – a headset is recommended. Or, call in using your telephone.


US phone number: +1 (312) 878-3080<tel:%2B1%20%28312%29%20878-3080>.

International Numbers:

Australia: +61 2 8355 1034<tel:%2B61%202%208355%201034>

Canada: +1 (647) 497-9376<tel:%2B1%20%28647%29%20497-9376>

France: +33 (0) 170 950 586

Germany: +49 (0) 811 8899 6931<tel:%2B49%20%280%29%20811%208899%206931>

Spain: +34 932 20 0506<tel:%2B34%20932%2020%200506>

United Kingdom: +44 (0) 330 221 0098<tel:%2B44%20%280%29%20330%20221%200098>


Access Code: 736-042-757

Audio PIN: Shown after joining the meeting

Meeting ID: 764-054-389
--
You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com<mailto:aatoc+unsubscribe at googlegroups.com>.
To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc at googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAOJhRMa9_G4gET-V0hNm7O%3Ddyq-4cwka_0fKwZKZqijwy91vMg%40mail.gmail.com<https://groups.google.com/d/msgid/aatoc/CAOJhRMa9_G4gET-V0hNm7O%3Ddyq-4cwka_0fKwZKZqijwy91vMg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Abuse and ATO Coordination" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aatoc+unsubscribe at googlegroups.com<mailto:aatoc+unsubscribe at googlegroups.com>.
To post to this group, send email to aatoc at googlegroups.com<mailto:aatoc at googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/aatoc/CAEeYn8geYEo5h%2By0Me19vZZ52vTKkp%2BJXOetq7%3DENv1vv-nawA%40mail.gmail.com<https://groups.google.com/d/msgid/aatoc/CAEeYn8geYEo5h%2By0Me19vZZ52vTKkp%2BJXOetq7%3DENv1vv-nawA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.





--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20150508/81dd4b25/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 18746 bytes
Desc: image001.png
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20150508/81dd4b25/attachment-0001.png>


More information about the Openid-specs-risc mailing list