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