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

Wed Dec 16 17:23:15 UTC 2015

Robert,

The duty to warn does not imply a right to block access. With respect to
personal health data, at least in the US, this has been confirmed and
reconfirmed many times and many ways. It probably will come up again in the
API Task Force but it does not have to be decided in HEART. All HEART needs
to do is to enable the "warn" while also giving the resource subject full
authority to bypass the "block". This is what limits the liability of the
RS while it enables both privacy AND security. This is what I called a Type
A Resource Server yesterday in this thread.

Other constraints may emerge from policy processes in the US and abroad but
those will be layered on top of HEART in various ways including trust
frameworks, registries, and exceptional controls at the RS that have
nothing to do with HEART.

Adrian

On Wed, Dec 16, 2015 at 11:30 AM, Robert Horn <robert.horn at agfa.com> wrote:

> 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
> <http://nate-trust.org>
>
> *From:* Openid-specs-heart [
> mailto:openid-specs-heart-bounces at lists.openid.net
> <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**@glenmarshall.com*
> <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* <gfm at securityrs.com>
> *www.SecurityRiskSolutions.com* <http://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*
> <Openid-specs-heart at lists.openid.net>
> *http://lists.openid.net/mailman/listinfo/openid-specs-heart*
> <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
>
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - *www.avg.com* <http://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
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/f2dd48d9/attachment-0001.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/f2dd48d9/attachment-0001.jpe>