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

Wed Dec 16 15:46:15 UTC 2015

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
<mailto:vendor.com at glenmarshall.com> @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

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