Re: [WG-UMA] A Wallet Authorization Server

21 Oct 2015

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