[Openid-specs-heart] The Number and Ownership of Authorization Servers.

Wed Dec 16 16:30:07 UTC 2015

This diverges significantly but to understand the risks you need to know 
harms and probabilities.  Is that person wrong about that email danger? 
What are the potential harms to that person? What are the probabilities 
that this exposure will result in harm?  What are the cumulative risks and 
correlated risks?  We've got pitifully little data.  That person who 
turned red might be entirely correct that for their situation and the PHI 
involved the integrated probability and degree of harm from disclosure is 
much less than the integrated probability and degree of harm from lack of 
disclosure. 

For example, I think the probable harm from disclosing my dentist 
appointment (which is PHI) in unprotected email is less than the harm from 
missing the appointment.  So I let them send email appointment reminders. 
I also do not let them use their web portal for me.  It looks poorly 
implemented and would expose too much else.

I think our goal in this is to establish mechanisms that will enable 
appropriate actions as we gain understanding of risks and as risks evolve. 
 Don't assume you've got the right risk assessment at the moment. 

Kind Regards,

Robert Horn | Agfa HealthCare
Interoperability Architect | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, Gotham Parkway 580, Carlstadt, NJ 07072-2405, 
USA
http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer 

From:   "Aaron Seib" <aaron.seib at nate-trust.org>
To:     "'Glen Marshall [SRS]'" <gfm at securityrs.com>
Cc:     openid-specs-heart at lists.openid.net
Date:   12/16/2015 10:46 AM
Subject:        Re: [Openid-specs-heart] The Number and Ownership of 
Authorization   Servers.
Sent by:        "Openid-specs-heart" 
<openid-specs-heart-bounces at lists.openid.net>

Awesome.  And on the other had – lest we all forget – we are the exception 
and there are people on the other side of the continuum who literally turn 
red when you try to explain to them that sending their PHI to an unsecure 
email address is fraught with dangers. 

If you think about it – that might be a case that we have to address. 

There are users who do not want to set up a AS at all – they just want 
their damn data.  Can we introduce something in the profile that tells the 
technologist how to configure that and more interesting – can that act as 
the users acknowledgement that they understand the risks and have chosen 
to go commando with their sharing preferences?

Aaron Seib, CEO
@CaptBlueButton 
 (o) 301-540-2311
(m) 301-326-6843

From: Openid-specs-heart [
mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Glen 
Marshall [SRS]
Sent: Tuesday, December 15, 2015 5:16 PM
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] The Number and Ownership of 
Authorization Servers.

Many people have already set-up things to establish privacy, in various 
ways and some more effective than others.  Multiple AS might be one of 
them.

For example, if I were enrolled in an HIV-positive clinical study, I might 
want the study's AS to contain my authorization just for access to the 
relevant RSs and not be noted in my clinical record.  The very fact of 
being enrolled in the study is too much of a disclosure.

Similarly, a person who has established a social networking account on an 
adult-interest web site might want to keep that out of sight from others. 
The mere existence of such privacy preferences in a common authorization 
resource might raise uncomfortable questions if they were revealed.  One 
solution is to have a distinct AS for the adult-interest site.  That can 
be generalized.

For privacy reasons, I give every one of my on-line vendor contacts a 
unique e-mail address to contact me, e.g., vendor.com at glenmarshall.com 
Even though all the e-mail comes to a common account for me to read, it 
makes it impossible for unrelated vendors to assemble and share a dossier 
keyed by e-mail.  Each vendor has my privacy and contact preferences 
relative to just cou common business.  With a large number of e-mail 
addresses I also avoid common identification services, e.g., OAuth, except 
where it suits my purposes.  A side-effect is that I do not need complex 
trust relationships among vendors.  This is not much of a schlep for me, 
once it was set-up. 

... and so on. 

Glen F. Marshall
Consultant
Security Risk Solutions, Inc.
698 Fishermans Bend
Mount Pleasant, SC 29464
Tel: (610) 644-2452
Mobile: (610) 613-3084
gfm at securityrs.com
www.SecurityRiskSolutions.com
On 12/15/15 15:10, Debbie Bucci wrote:
Yes I believe ...some poor schlep is going to be on the hook for keeping 
his AS replicated with the one I designated because of  “Policy”

AND  (ideally) 

The trusted  application that you are familiar designate (Bill's source of 
truth) would/should trigger/drive the updates. 

Perhaps a schlep provide UI to verify update and changes (and trigger 
receipts of those update)  -  would be considered a safeguard.

Given your experience with PHRs - you know best - there maybe one source 
of truth for Healthcare data today but with IOT and other yet to be 
determined innovations -  I still believe (under the covers) it will be 
distributed in nature.

Understanding that going in may impact some of our decisions. 

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7294 / Virus Database: 4483/11177 - Release Date: 12/14/15
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/e2dc1042/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/e2dc1042/attachment.jpe>