Adrian,From my perspective, most of the answer is already in your question.(a) technical code on GitHub, open(b) legal code on GitHub, open(c) policies, logs, signatures, dates, deal points, etc. in the parties' PDSs. If the parties want to keep a private copy on GitHub, GitLab or other git hosting service, that may make for good backup and management.Some materials will start as private but later be published as (b) or (a). For instance, an organization may take its terms and publish them to make it easier to deal with the organization, to increase confidence in those terms or in a bid to have its preferred terms become a standard.On Tue, Dec 22, 2015 at 2:27 PM, James Hazard <jh@hazardj.com> wrote:Excellent. Will get to this in a couple of hours. Need to attend to other duties. Here is Fabulous-HallTunes:It reaches a little deeper into the UMA provisions to get just the RqP obligation to RSO (instead of all RqP obligations).On Tue, Dec 22, 2015 at 2:13 PM, Adrian Gropper <agropper@healthurl.com> wrote:Let's now focus on adoption for a bit. Each of the entities (RSO, ASO, RqP) has purchased an UMA hardware kit from C.H.I.P for $30 and each entity has associated files of three kinds:(a) code - mostly public and community supported(b) contracts as described by Jim below - mostly public and community supported(c) policies, logs, and other data tables that are exclusively and securely the entity's - always private(a) wants to be public for security reasons.(b) needs to be public to make it easier for communities to create interoperable Things.(c) needs to be private because each entitie's policies are nobody's business.How does UMA use GitHub to facilitate the creation of interoperable Things?Adrian
On Tuesday, December 22, 2015, James Hazard <jh@hazardj.com> wrote:Each is a separate file, rather than repo. I did them as if RSO - ASO was first and leveraged it to make RqP - ASO. They could be independent of one another, though there is also advantage in reflecting the steps of a transaction.The "repos" - collections of files - are in the control of the parties, so each of RSO, ASO and RqP would have a repo. They are like PDSs.If there is an RSO - RqP file, it could be i) a third-step in the documentation, referencing the ASO - RqP or ii) independent. It would be in the repos of RSO and RqP, plus ASO if so agreed.
- ASO would have full copies of both files, plus as much of the underlying UMA materials she wished to have locally.
- RSO would have the RSO - ASO and nothing else, unless it was agreed that RSO also get a copy of ASO - RqP (there may be business and legal reasons for RSO to want to know what terms AP is doing with the key).
- RqP would have RqP - ASO and i) as much of the underlying RSO - ASO as was used in expanding that document - or ii) more, depending on the business and legal considerations. The first alternative requires access control at the key=value (property) level.
On Tue, Dec 22, 2015 at 1:33 AM, Adrian Gropper <agropper@healthurl.com> wrote:Adrian2 - I agree that a contract between the RSO and RqP is an option. It's easier if it's not required but if it is, is that a separate Common Accord repo?So now we have the next two questions:1 - The two contracts (RSO - ASO and RqP - ASO) are separate but have the ASO in common. Keeping in mind that these two contracts are executed at totally different times, does Common Accord as applied to UMA link these two contracts together or leave them as separate repositories in GitHub?On Mon, Dec 21, 2015 at 6:16 PM, James Hazard <jh@hazardj.com> wrote:Room service now available:I didn't have a Bob on tap, so its Fabulous, signed by Barclay.The part of the text that is not drawn from UMA should be treated as lorem ipsum.I would think that the RqP (Fabulous Express) would want an agreement with the RSO (Hotel), at least so that it is not accused of trespass, and liability stuff is covered.The second document draws from the first. This is a quick way to create a flow of a transaction. It also presents a nice issue of managing access to the elements of the documents themselves.On Mon, Dec 21, 2015 at 11:00 PM, Adrian Gropper <agropper@healthurl.com> wrote:AdrianWhere's the contract between Bob Client and Alice ASO?Jim,This is only one of the contracts - between Hotel RSO and Alice ASO--On Mon, Dec 21, 2015 at 4:34 PM, James Hazard <jh@hazardj.com> wrote:This is a wonderful example to work from. Perhaps we say that the door is a hotel room (adding another person as Resource Server Operator) and that Alice is the guest and she wants to give Bob permission to leave off a package, or something like that?I haven't had much time and may not get more until tomorrow, but here is an Alice and hotel frame for an agreement.On Mon, Dec 21, 2015 at 7:58 PM, Adrian Gropper <agropper@healthurl.com> wrote:_______________________________________________The use-case is pretty simple:To help make UMA easier to understand and adopt, I'd like to propose a very simple IoT use-case.As background, check out the 1:23 video of McAffe pitching EveryKey. https://www.indiegogo.com/projects/everykey-your-only-key#/ What would this look like if all the locks, keys, and authorization servers were totally UMA standard and cost around $30?
- A door lock is a Non-Person Entity. It's the UMA Resource Server and, in addition to Resource Registration, it typically executes three commands: Register Key, Unlock Door, and De-register Key. The Resource Server Operator (RSO) is a home or office entity.
- A key is an UMA Client, typically associated with a single person that might live in the home (Alice) or might visit occasionally (Bob). The key has two "buttons" labeled Register and De-Register. We make the assumption that all locks within a couple of feet unlock by proximity and that Register and De-Register add some kind of pairing dance such as a button and light on the lock and key.
- Alice lives in the home and has an UMA Authorization Server. Alice's AS is generic and doesn't know anything specific to locks. Alice doesn't share her AS with her roommates. Alice is able to register her AS with the lock by authenticating with the RSO in-person.
- Alice is now able to enable access by her friend Bob by sending to his smatphone an invitation email or text pointing to her unlock resource on the lock. Bob will use his Bluetooth key and his smartphone to register with Alice's AS and gain access.
If Alice's AS happens to be nearby, this use-case might happen entirely over Bluetooth with no connection to the Internet. In this case, the status of the SSL certificates cannot be checked but everything should work. Other than the SSL certificates such as Let's Encrypt, this use-case leaks no private data to the cloud or to any external entities.
The lock, the key, and Alice's AS are all assumed to be separate open source technologies. There are bilateral contracts between the operators of the lock (RSO), Alice as the AS operator (ASO), and Bob as responsible for the key (RqP). These contracts must all include a provision for Notice to the counter-party of the contract if the lock, AS, or key are lost or otherwise compromised.
Ideally, each of the three technology actors (lock, key and AS) in this use-case could be a C.H.I.P. https://en.wikipedia.org/wiki/Next_Thing_Co. (It would be better if CHIP included a secure element, but that's a peripheral issue).
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/
_______________________________________________
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 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/