Thanks, Tim. Your observation is very helpful.

Medicine, and maybe other regulated business, is not well suited to a P2P environment in the redecentralize http://redecentralize.org/conference/sessions.html sense. I will never be a peer with either my hospital or my insurance company. In medicine, even the HIPAA covered entities have trouble being peers with each other. There are no broad federations in healthcare even to the extent we have some ATM, Swift, and ACH federations in banking.

Healthcare is what Tim is calling the "box world" and the boxes have my data and set the rules. My strategy is to play by box rules and if there's any blockchain component it may or may not be visible to the boxes. My goal is to make a patient-specified AS practical and acceptable to both boxes and people. My strategy is to try and change as little about the legal landscape and the user experience as possible.

For example, the WAS authorization server would implement a NASCAR interface of (OpenID Connect) IDPs so that a RO could outsource RqP authentication by default. Another default might ask the RO to approve dynamic client registration by a RqP via text message. From a user experience perspective, an RO that launches an instance of WAS and accepts the defaults should just get an email and text with the URL of their WAS ready to use on whatever ROI form they're presented by hospitals, banks, or other service providers. (I know that we will need more security options than these defaults, but I'm just trying to be clear about the technical foundation.)

From a legal perspective the WAS would be designed to operate under the HIPAA "patient right of access". Can we shield any RS (not just healthcare) from any liability for how the RO configures their AS? Can we define UMA in a way that creates a generalized "safe harbor" for any institution that accepts an RO-specified AS?

The WAS BLT sandwich would have a free open source AS as the B, a "safe harbor" for any RS that accepts an RO-specified AS as the L, and an RO choice of IDPs as the T.

Adrian

On Sat, Oct 17, 2015 at 12:14 AM, BridgeIDentity <tim@bridgeidentity.com> wrote:

I see the errors of complexity again.
If you live in a box world, you must look like a box even if you want to be and feel you are a circle.
The block chain architecture allows a more user centric platform moving forward and with less complexity.
I am not sure how you will unravel this and how you can take valuable components and apply them in a resourceful manner.
UMA I believe does not truly address the transformation of many to one to one to many data in a cultural transition.
Blockchain allows for this architecture to begin, and for that reason “I am Out”.

Tim

From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Dazza Greenwood
Sent: Friday, October 16, 2015 2:43 PM
To: Adrian Gropper
Cc: wg-uma@kantarainitiative.org WG
Subject: Re: [WG-UMA] A Wallet Authorization Server

Where is the BLT sandwich? That really is the question.

Are there any parties you know of who are using UMA for some/any business purpose today (ie not for testing or because they "have to" for some reason) and who might be interested in this? If so, we'd have a reasonable starting basis to discuss potential business and legal arrangements that may be acceptable to the parties. Best of all, by starting with actual parties it is possible to check back with them later to test whether the ideas are or are not likely to be acceptable in practice... by arranging a demo, pilot or other explore and then asking them.

I want a BLT sandwich as much as anybody, but am unaware of any way to establish business and legal acceptability without knowing realistic information about the parties, their transactions and the context of their relationships with one another. If you don't have business and legal parties (as in parties who are in fact using or exploring business use of the system) then you really can only test a T sandwich and make educated guesses about the B and the L. So, your BLT sandwich is with parties who do or are actively considering using UMA for their regular business purposes and can be involved in some type of user testing or other feedback cycle.

The B comes first because it is the meat. If you only have T and even L and T, you should be asking: Where's the Beef?

_ _ _ _ _ _ _ _ _ _ _ _ _ _
| Dazza Greenwood, JD
| CIVICS.com, Founder & Principal
| MIT Media Lab, Visiting Scientist
| Vmail: 617.500.3644
| Email: dazza@CIVICS.com
| Biz: http://CIVICS.com
| MIT: https://law.MIT.edu
| Me: DazzaGreenwood.com
| Twitter: @DazzaGreenwood
| Google+: google.com/+DazzaGreenwood
| LinkedIn: linkedin.com/in/DazzaGreenwood
| GitHub: github.com/DazzaGreenwood/Interface
| Postal: P.O. Box 425845 Cambridge, MA 02142
| _ _ _ _ _ _ _ _ _ _ _ _ _ _

On Fri, Oct 16, 2015 at 10:35 AM, Adrian Gropper <agropper@healthurl.com> wrote:
Available as a service: could be satisfied with a $5/mo VM and a https://letsencrypt.org/ cert?
Speaks standard UMA: can WAS be a profile on UMA 1.0.1 or does it need UMA 2.0?
Dynamic client registration: ROs can choose their app (store) whitelists - what has this to do with UMA?
Acceptable to other entities/parties at the business and legal level: what can UMA do to help this?
That last one is the key to UMA adoption. If the legal and business barrier is low then adoption might follow the Bitcoin / blockchain model where adoption is driven by a combination of branded centralized services and pure p2p energy. CommonAccord and emerging blockchain inspired governance models will also help reduce the legal and business barrier.
Where's my BLT sandwich?
Adrian

On Thu, Oct 15, 2015 at 9:31 PM, Eve Maler <eve@xmlgrrl.com> wrote:
As long as the AS is available as-a-service (that is, doesn’t frequently get shut down), speaks standard UMA, handles the more “dynamic” patterns (such as being able to hand out client credentials readily to OAuth clients it hasn’t met before), and is acceptable to other entities/parties on a business/legal level and vice versa (whatever those constraints and concerns might be), I’m not sure what other compatibility concerns there are.

Eve

On 15 Oct 2015, at 1:19 PM, Adrian Gropper <agropper@healthurl.com> wrote:

Imagine the authorization server as an on-line wallet: secure, compatible regardless of jurisdiction, and owned. It would share a lot of the attributes and business issues of Bitcoin wallets. For lack of a more inspired name, I will call it a Wallet Authorization Server or WAS.

Like Bitcoin wallets, the WAS will be delivered to individuals as either a VM they can run on hardware / VMs they control or not. Individuals will choose sovereignty vs. convenience.

Do we want to drive future versions of UMA in this direction? If so, what are the minimum essential components of the WAS in order to make it compatible with all UMA resource servers and all clients that are willing to support a truly user-centric model?

Adrian
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

--

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/

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma

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/