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

Wed Dec 16 16:33:12 UTC 2015

Just when I thought I was out of this thread, you pull me back in. :-)

Very high-level thoughts about what users will want to do: It all depends
on availability of options. When it comes to UMA-conforming services:

   - There are zero "full-choice" (wide-ecosystem) consumer-facing AS
   options today.
   - There are zero "partial-choice" (medium-ecosystem) AS options offered
   by organizations working within an existing circle of partners, say,
   providers or payers.
   - In the next small handful of quarters, we can expect a small number of
   "no-choice" (narrow-ecosystem) AS options offered by individual
   organizations.

I believe these last will likely closely resemble the existing online
"configure your sharing preferences" UX's that users are familiar with,
adding "empowerment" features such as finer-grained access approvals (vs.
ordinary OAuth consent) only as a new kind of advanced feature available
for those special few who need/want/seek it. Part of the value of deploying
UMA by these organizations will be to enable those ecosystems to grow in
scope over time (e.g. to more easily cover partner APIs and third-party
clients), and another part of the value is to add "strategic" data
protection capabilities vs. "tactical" ones that stay only one step ahead
of regulators (see: the EU GDPR announcement of yesterday!).

Someday, it is to be hoped that individuals will have lots of market
choices of "full-choice" AS's (yes, that's the best plural I could come up
with -- sorry!). And then we will have a new set of interesting problems on
our hands regarding portability and "aggregatability" of the stuff that
resides in AS's, so that people can move between them, do analytics over
that stuff, etc.

*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 7:46 AM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> 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] *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
> <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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151216/734784d2/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/734784d2/attachment.jpg>