Re: [WG-UMA] UMA MVP for IoT

22 Dec 2015

      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.

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

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.

On Tue, Dec 22, 2015 at 1:33 AM, Adrian Gropper 
wrote:
...
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?
2 - 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?
Adrian
On Mon, Dec 21, 2015 at 6:16 PM, James Hazard  wrote:
...
Room service now available:
http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/PandaPass/Alice-FabulousExpress_ToU_0.md
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 
wrote:
...
Jim,
This is only one of the contracts - between Hotel RSO and Alice ASO
Where's the contract between Bob Client and Alice ASO?
Adrian
On Mon, Dec 21, 2015 at 4:34 PM, James Hazard  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.
http://www.commonaccord.org/index.php?action=doc&file=GHx/KantaraInitiative/PandaPass/Alice-HallTune_ToU_0.md
On Mon, Dec 21, 2015 at 7:58 PM, Adrian Gropper 
...
wrote:
...
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?
The use-case is pretty simple:
- 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).
Adrian 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/
_______________________________________________
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/