I'm resuming this thread after a bunch of side conversations in this UMA thread and the [Legal] thread here. 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:

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 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/