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 <agropper@healthurl.com> 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

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma