I'm resuming this thread after a bunch of side conversations in this UMA thread and the [Legal] thread here <http://kantarainitiative.org/pipermail/wg-uma/2015-October/003907.html>. The main goal of the WAS thread is: To promote UMA adoption by giving away a reference implementation of a general-purpose personal authorization server. The idea is to reduce both the risk and the complexity of any UMA implementation by encouraging both RS and C, in whatever industries they happen to be, to demonstrate compatibility with the generic and unmodified WAS reference implementation. *BLT observations are*: - The B is a non-commercial open source community of folks interested in promoting UMA by distributing a useful piece of code in the form of an UMA Authorization Server that could be used by any individual if the RS allows a user-specified AS. The B reasons for why an RS would want to allow a user-specified AS are out of scope but suggestions are most welcome. In general, a user-specified AS is most useful in use-cases where governance and jurisdiction are a barrier to interoperability and a customer-centric approach can bypass this problem. I suggested blockchain (Bitcoin adoption) as an example of business adopting a federation and jurisdiction-free approach based on individual sovereignty. An open source useful piece of code can succeed by creating secondary business opportunities. - The L is a simple-minded approach that keeps all of the legal and business constraints entirely under the RS control. A personal open source authorization server like WAS does not introduce a new party into the equation. From the RS and C legal perspective, the WAS is equivalent to the customer's Web browser. The idea here is to short-circuit extensive legal analysis by simply translating the RS's current release of information contracts into an UMA-compatible format. In some domains, this legal "safe harbor" is actually regulated as a "customer right of access". - The T is to deliver a virtual machine that any individual can run (hosted or unhosted) with growing functionality over time. As Eve puts it: "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)..." Eve goes on to say: "... and is acceptable to other entities/parties on a business/legal level and vice versa (whatever those constraints and concerns might be)". To this last point, I refer back to the simple-minded legal approach above where we avoid introducing any new actors to the WAS party. *What are the gaps between UMA 1.0.1 and a WAS reference implementation? * These seem to fall into two categories related to (a) identity and access to identity attributes of the requesting party, and (b) vocabulary issues specific to an industry or domain that would prevent a generic and person centered reference imlementation. (a) * Identity*: The RqP may not agree to present claims to any random and untrusted AS and the RS may need verified attributes about the RqP in order to meet legal or business mandates. As Eve puts it: "If you think of an AS as an RP/claims client, then the RqP might be worried that the AS is going to be exposed to the RqP’s PII, and the RqP might be worried about the AS’s capacity to keep that data safe etc. This falls into the category of good security and privacy practice, nothing UMA-specific. It may also fall into the category of regulated care of PII" A generic WAS could present the RO with one or more of these four options for registering clients and issuing authorization tokens: - AS issues local credentials (password, SSH, FIDO) - this is the trivial minimum. - AS accepts RqP authentication by the RS - this is no worse than the pre-UMA situation and it presents no new legal or business risk to the RS. - AS accepts a federated authentication, including blind credential brokers that protect the RqPs attributes from both the AS and the RS. - AS accepts public claims via a blockchain mechanism like OneName https://onename.com/ Note that none of these are domain specific and at least one allows the RS to take responsibility for Bob and seal the interop deal. According to Eve, the Client needs to know what claims are of interest and this could be specific to the RS and the domain. I hope UMA can keep this a matter between the RS and C as much as possible but I agree that really sophisticated policy calculus by the AS would turn into a vocabulary interop problem. (b) *Vocabulary*: (b) The AS currently needs extensions to compute on domain-specific vocabulary. Neither the RS nor the AS should be forced to accept executable code from anywhere. I see one or more of the following options: - The resource registration process has no domain-specific vocabulary (e.g.: release 1 BTC to the C from this account, or release the PDF document associated with this resource), allow read but not write, etc... - The RS sends a blank HTML form to the AS with whatever scopes and scope descriptions it chooses along with contract boilerplate and links to published terms of use and privacy policies. The form is typically a public document and may be a standard. 1. The RO fills in the form and stores it at the AS 2. The blank form is available to the RqP via the RS or the AS 3. The RqP makes a request via the form and presents claims 4. The AS issues a permission token based on the stored form and may also respond to simple introspection requests as defined by the form 5. The RS manages the transaction and sends a receipt with the applicable scopes back to the AS About this, Eve says: "Here this is some putative UMA that doesn’t exist, I’m afraid. Resource set descriptions currently get registered by the RS at the AS independently of any particular RqP/client. What gets registered is: Resource X with possible scopes y and z is now under your protection. Alice can then go to the AS and create policies that map “subjects” (actually some mix of client/requesting party descriptors) to resource sets and specific scopes, like this: "Dr. Bob (using client ccc?) can get access to resource X with scope y (perhaps up until time limit T) (perhaps only if strongly authentication in manner A) (etc.)." This enables the AS to know what precise claim descriptors etc. to ask for when Dr. Bob and his client approach seeking access. If they match the descriptors, then what gets put in the client’s token is a permission block saying: “(This subject — it’s actually implicit from the token’s bearer in the current profile) can get access to resource X with scope y (perhaps and this permission expires at time limit T) (etc.)." Clearly, a generic WAS, incapable of computing on domain vocabulary would not be able to offer this kind of control to the RO. It would need to trust the RS to offer a limited menu of options that the RO would pick from at resource registration time. Any negotiation or complexity in requesting claims would need to occur between the RS and the RqP/C directly and the AS would simply be notified of the outcome as with a Consent Receipt. In summary, I propose that UMA adoption would be well served by an approach that avoids any change in the Business or Legal practice of the Resource Server (by not introducing any new parties or federations) and facilitates the Technical conversion to UMA by providing a Free generic and personal authorization server for both RS and C to test against. Another perspective on this action item is available here: http://kantarainitiative.org/pipermail/wg-uma/2015-October/003907.html Here's a websequencediagram <http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQmFzZWxpbmUgSEVBUlQgU2VxdWVuY2UgRGlhZ3JhbQoKcGFydGljaXBhbnQgIkFsaWNlIHJlc291cmNlXG5vd25lciAoUk8pIiBhcyBSTwAhDk5QRQAiC3NlcnYAKQVTACcHUwBOD2dlbnQgYXV0aG9yaXphdGlvbgArCkEALgdBACYPQm9iIGNsaWVudFxuYXBwIChDAIEFBkMAFRJyZXF1ZXN0aW5nXG5wYXJ0eSAoUnFQAIEzB3FQCm5vdGUgb3ZlciBSTywgUlMsIEFTLCBDLAAYBU5QRSA9IE5vbi1QZXJzb24gRW50aXR5IC8gVGhpcyBpcyB0aGUgSW5kaXZpZHVhbC10by0ABAogRGVzaWduIFBhdHRlcm4KZW5kIG5vdGUKCgpSTy0-UlM6IFByZXNlbnRzIEluIABdBgpSUy0-Uk86IEdldHMgQ3JlZGVudGlhbAAqCVNpZ24gSW4gdG8gTlBFIFBvcnRhbAAtCURpc3BsYXkAFgVST0kgRm9ybQAxCnBlY2lmeSBBdXRoJ3ogUwCCXAoAgQgJVGV4dCBSAINkByBEZXNjcmlwdGlvbgCBLgVBAHIOAIM2BgB7BwCBNAVBUzogRkhJUgAtFkEAgVQHAEMiQ29uZmlybQCBJQUAhA8JIFBvbGljaWVzAEMGAB0KXG4AgSkJUmVnaXN0cgCEQwUAgQkJQ29uc2VudCBSZWNlaXB0CgCDYBUKIEVuZCBvZiBVTUEgUGhhc2UgMQCDKAsAhB0LAIQWDiBScVAgZGlzY292ZXIAhAsGAIYjCCB2aWEgbWVzc2FnZSBvciBkaXJlY3RvcnkgcXVlcnkAhAYLUnFQAIJYBgCECAlDbGFpbXNcbmUuZy4gYm9iQG1lZGljYWxzb2NpZXR5Lm9yZwCCSgZxUACEGRMARwgAgyEMUwBcCk1heSBuZWVkIHRvAIIrB2VyIEMAhkwFAIMgBUMAgiISQwCDeAZSAIZJBnMAgwwOAC0IR3JhbgALEQCCIBsAgmERMgCGGwogCkMAhh4GQWNjZXNzAIRJDgCEZAlBY2NvdW50aW5nIGZvciBEaXNjbG9zdXIAgxUdAINYETMAhxAMCg&s=mscgen> that illustrates WAS that I created for the HEART discussion: title Baseline HEART Sequence Diagram participant "Alice resource\nowner (RO)" as RO participant "NPE resource\nserver (RS)" as RS participant "Agent authorization\nserver (AS)" as AS participant "Bob client\napp (C)" as C participant "Bob requesting\nparty (RqP)" as RqP note over RO, RS, AS, C, RqP NPE = Non-Person Entity / This is the Individual-to-Individual Design Pattern end note RO->RS: Presents In Person RS->RO: Gets Credential RO->RS: Sign In to NPE Portal RS->RO: Display NPE ROI Form RO->RS: Specify Auth'z Server (AS) RO->RS: Text Resource Description RO->AS: Sign In to Agent Portal RS->AS: FHIR Resource Description AS->RO: Text Resource Description RO->AS: Confirm Authorization Policies AS->RS: Confirm\nResource Registration RS->AS: Consent Receipt note over RO, RS, AS End of UMA Phase 1 end note note over RS, AS, C, RqP RqP discovers the resource via message or directory query end note RqP->AS: Presents Claims\ne.g. bob@medicalsociety.org AS->RqP: Gets Credential RqP->AS: Sign In to AS RqP->AS: May need to Register Client AS->C: Consent Receipt C->AS: Requests Authorization AS->C: Grants Authorization note over RS, AS, C, RqP End of UMA Phase 2 end note C->RS: Access FHIR Resource RS->AS: Accounting for Disclosure note over RS, AS, C, RqP End of UMA Phase 3 end note -- 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/