• I suspect reasonable people can disagree on what the complex parts are and what the simple parts are, depending on what parts of a system they are responsible for.

• There has been a robust conversation in IIWs past about the proposition of a server that would be totally controlled by the individual. Adrian convened a very interesting session at IIW 20 that resulted in these notes, called “My OWN $5/mo UMA Authorization Server”. It would be cool to do this again and see how far we’ve come. It’s been very tough to get “user-centric identity/access servers” going as a real-life attractive proposition, but it could still happen at some point.

• I had an ongoing conversation with Steve Greenberg* this weekend, who pointed out a curious phenomenon: In the world of identity, we’ve had the “T” for a very long time, but we’ve sometimes struggled with the “B”, and the “L” situation is pretty immature. (Which is why I glommed on to Tim Reiniger when I first met him — he had a lot to do with authoring the Virginia digital identity law!) But in the world of consent and trust and so on, it’s really about agency — and we’ve actually had the “B” and “L” elements for a long time; the “T” element is the new guy at the table. [He wants me to call him “Steve Greenberg, noted raconteur and bon vivant” :-) ]

• OAuth (6749 and 6750 together) is about 96 pages on my printer. OIDC Core all by itself, ignoring the other important specs, is 93. UMA Core is 34 and RSR is 23. At least by the metric of the technical complexity that it adds on top of the other pieces, I’m not sure UMA’s “T" is all that complex.

• As for “where the beef is”, in my own world I have several examples of business model #1 (easy) coming up, and, increasingly, some instances of business model #2 (medium). Business model #3 — Adrian’s goal — is the hardest. The reason we have a legal subgroup at all is to accelerate comfort with/reduce inhibitors to deploying the harder cases. The WG’s work is generally “(B)T” at this point, and the legal subgroup is generally “BL”.

• Looking at the provided diagram, I’m not sure I understand the blockchain connection, as UMA is, by design, identity-ignostic and you can get pretty far without having to use “the same identity” in many UMA-related contexts (e.g., an RO can use a different identity at each RS and the AS and — when acting as an RqP — at each client, and authorization can be based on non-uniquely identifying factors of an RqP through “claims-based access control”). Would love to understand this better.

On 16 Oct 2015, at 6:20 PM, Adrian Gropper <agropper@healthurl.com> wrote:

On Fri, Oct 16, 2015 at 3:43 PM, Dazza Greenwood <dazza@civics.com> wrote:

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? 

I should know better than to argue with a lawyer, in public, but I can't resist...

UMA is already too complicated for its own good. I've been in a position to work on UMA-related things as much as anyone from the B perspective except probably Eve. The legal subgroup discussions are thrilling, but they are not headed in the direction of reducing UMA's complexity. CommonAccord and consent receipts will be huge contributions to UMA but we need to consider the UMA adoption model as a whole.

UMA's path to success lies in packaging the LT goodies with the simplest possible B by giving away a fully functional personal Authorization Server. This will provide the essential reference implementation at the root of any new standard. It's unreasonable to expect anything as complex as UMA to take off when people have to digest OAuth, OpenID Connect, federation, servers, scopes, clients, and agency before a single transaction takes place.

The B I'm proposing is a non-profit community chartered to promote UMA to individuals as a component of both decentralized and corporate services. The L and T can include CommonAccord and MVCR and any other technology that will reduce the barrier to UMA for RS and C developers.

Adrian

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