A Wallet Authorization Server
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 <http://patientprivacyrights.org/donate-2/>
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 <http://patientprivacyrights.org/donate-2/>_______________________________________________ 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
- 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 <http://patientprivacyrights.org/donate-2/> _______________________________________________ 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/
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 <http://patientprivacyrights.org/donate-2/> _______________________________________________ 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
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 <http://patientprivacyrights.org/donate-2/> _______________________________________________ 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/
Some food for thought... 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 <http://iiw.idcommons.net/My_OWN_$5/mo_UMA_Authorization_Server>, 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 <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Business-Models> #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. FWIW… Eve
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 <mailto: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 <mailto:agropper@healthurl.com>> wrote: Available as a service: could be satisfied with a $5/mo VM and a https://letsencrypt.org/ <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 <mailto: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 <mailto: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?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
Hmmm... that's a lot of good ideas and options to digest. Thanks you, Eve! Do you happen to know if the innovative ideas from IIW have been advanced anywhere by anyone? (this: http://iiw.idcommons.net/My_OWN_$5/mo_UMA_Authorization_Server) _ _ _ _ _ _ _ _ _ _ _ _ _ _ | 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 Mon, Oct 19, 2015 at 12:14 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Some food for thought...
- 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 <http://iiw.idcommons.net/My_OWN_$5/mo_UMA_Authorization_Server>, 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 <https://github.com/KantaraInitiative/wg-uma/wiki/UMA-Legal:-Business-Models> #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.
FWIW…
Eve
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?
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com
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 <tel:%2B1%20425.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/> http://patientprivacyrights.org/donate-2/ _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Thanks, Tim. Your observation is very helpful. Medicine, and maybe other regulated business, is not well suited to a P2P environment in the redecentralize http://redecentralize.org/conference/sessions.html sense. I will never be a peer with either my hospital or my insurance company. In medicine, even the HIPAA covered entities have trouble being peers with each other. There are no broad federations in healthcare even to the extent we have some ATM, Swift, and ACH federations in banking. Healthcare is what Tim is calling the "box world" and the boxes have my data and set the rules. My strategy is to play by box rules and if there's any blockchain component it may or may not be visible to the boxes. My goal is to make a patient-specified AS practical and acceptable to both boxes and people. My strategy is to try and change as little about the legal landscape and the user experience as possible. For example, the WAS authorization server would implement a NASCAR interface of (OpenID Connect) IDPs so that a RO could outsource RqP authentication by default. Another default might ask the RO to approve dynamic client registration by a RqP via text message. From a user experience perspective, an RO that launches an instance of WAS and accepts the defaults should just get an email and text with the URL of their WAS ready to use on whatever ROI form they're presented by hospitals, banks, or other service providers. (I know that we will need more security options than these defaults, but I'm just trying to be clear about the technical foundation.)
From a legal perspective the WAS would be designed to operate under the HIPAA "patient right of access". Can we shield any RS (not just healthcare) from any liability for how the RO configures their AS? Can we define UMA in a way that creates a generalized "safe harbor" for any institution that accepts an RO-specified AS?
The WAS BLT sandwich would have a free open source AS as the B, a "safe harbor" for any RS that accepts an RO-specified AS as the L, and an RO choice of IDPs as the T. 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/
Adrian, I have attached a blockchain/sidechain sample cluster diagram showing all of my TLD domains (.com) that we intend to formalize into Decentralized Organizations with supportive sidechains. Each of these would maintain unique user/sponsor managed identities and with Oath or Open Connect, one would move from one to another. As you can see, Patient ID is a small but important unit of play given the breadth of the identity architecture overall. I feel by providing persistent identities in the block/side chains, we can better serve the individual and entities ownership worldwide. There are many industries looking for identity solutions in the same conundrum. Hope this sheds some light. Tim From: agropper@gmail.com [mailto:agropper@gmail.com] On Behalf Of Adrian Gropper Sent: Saturday, October 17, 2015 1:08 PM To: BridgeIDentity Cc: Dazza Greenwood; wg-uma@kantarainitiative.org WG Subject: Re: [WG-UMA] A Wallet Authorization Server Thanks, Tim. Your observation is very helpful. Medicine, and maybe other regulated business, is not well suited to a P2P environment in the redecentralize http://redecentralize.org/conference/sessions.html sense. I will never be a peer with either my hospital or my insurance company. In medicine, even the HIPAA covered entities have trouble being peers with each other. There are no broad federations in healthcare even to the extent we have some ATM, Swift, and ACH federations in banking. Healthcare is what Tim is calling the "box world" and the boxes have my data and set the rules. My strategy is to play by box rules and if there's any blockchain component it may or may not be visible to the boxes. My goal is to make a patient-specified AS practical and acceptable to both boxes and people. My strategy is to try and change as little about the legal landscape and the user experience as possible. For example, the WAS authorization server would implement a NASCAR interface of (OpenID Connect) IDPs so that a RO could outsource RqP authentication by default. Another default might ask the RO to approve dynamic client registration by a RqP via text message. From a user experience perspective, an RO that launches an instance of WAS and accepts the defaults should just get an email and text with the URL of their WAS ready to use on whatever ROI form they're presented by hospitals, banks, or other service providers. (I know that we will need more security options than these defaults, but I'm just trying to be clear about the technical foundation.)
From a legal perspective the WAS would be designed to operate under the HIPAA "patient right of access". Can we shield any RS (not just healthcare) from any liability for how the RO configures their AS? Can we define UMA in a way that creates a generalized "safe harbor" for any institution that accepts an RO-specified AS?
The WAS BLT sandwich would have a free open source AS as the B, a "safe harbor" for any RS that accepts an RO-specified AS as the L, and an RO choice of IDPs as the T. 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 <tel:%2B1%20425.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/> 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/> http://patientprivacyrights.org/donate-2/
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/
participants (4)
-
Adrian Gropper -
BridgeIDentity -
Dazza Greenwood -
Eve Maler