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

Thu Dec 17 05:11:24 UTC 2015

Aaron, your interpretation is correct.

We're working hard in the UMA legal subgroup to reduce friction even for
those interested in *voluntarily* deploying ecosystems wider than one
millimeter :-) -- but nonetheless, regulations often serve as a forcing
function.

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Wed, Dec 16, 2015 at 9:46 AM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Very well said Mr. Horn.
>
>
>
> And I completely agree.  I hate to say it but to date the opposite extreme
> that has been swaying over the appropriate sharing of PHI with consumers
> (i.e., that want to map the requirements we expect of providers to the
> consumer as well) is doing more harm at the expense of individual consumers
> than good.
>
>
>
> We’ve stood by the position that the risks associated with a Provider
> exchanging PHI with another Provider about N# of consumers is greater than
> when an exchange between the Consumer and a Provider is being considered
> and as a result the requirements associated with the consumer should be
> different in comparison to the requirements of a Provider who has a
> professionally defined role that under HIPAA gives him\her the authority to
> share data about consumers without their consent as a practical necessity
> in delivering care.
>
>
>
> Today, as far as I am aware of applicable law, there is nothing that
> compels a Provider to reference a consumer’s HEART Profile before sending
> data to another Provider except if the Provider commits to do so in their
> NPP.
>
>
>
> Eve sent out an email defining the continuum of adoption of AS using these
> terms:  "full-choice" (wide-ecosystem); "partial-choice"
> (medium-ecosystem); "no-choice" (narrow-ecosystem) which I am not sure I
> understood the use of the word ‘choice’ but I got the overall gist of her
> message to be that as of today we are on the far right of the spectrum
> where very few Covered Entity’s enterprises would be able to support the
> consumer’s choice of an AS *not* owned by the enterprise.
>
>
>
> Perhaps the choice Eve is referring to is the consumers power to vote with
> their feet and only seek care from Covered Entities whose NPP indicates
> that they will employ the AS of the consumers choice.  Lacking legislation
> requiring CEs to do this that is my understanding of how we will migrater
> from the right hand end of the spectrum to the left.
>
>
>
> Am I missing anything that you guys have already addressed?
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Robert Horn [mailto:robert.horn at agfa.com]
> *Sent:* Wednesday, December 16, 2015 11:30 AM
> *To:* aaron.seib at nate-trust.org
>
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] The Number and Ownership of
> Authorization Servers.
>
>
>
> 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
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/e53999a4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/e53999a4/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 3143 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/e53999a4/attachment-0003.jpg>