The analysis doc is here (and was linked in the meeting minutes contained in the message where I asked for solution proposers to present). The goal is to see how solutions stack up to the challenges presented. In this case, the challenges of "no assumption of any particular trusted federation" and, I imagine, also "Bob's experience" would be relevant.

(I'd observe that one way existing smart doorbell systems handle the dynamics of a totally unknown person showing up is that Alice herself checks the "requesting party" and the latter doesn't have a client at all -- they present their face as a sort of "claim", and Alice can synchronously choose to unlock the door. Not sure how/whether to map this use case directly, vs. someone wielding an actual client.)


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Tue, Apr 12, 2016 at 5:33 AM, Adrian Gropper <agropper@healthurl.com> wrote:
John,

#wideeco requires 6 things:
- low cost
- limited or no connectivity 
- no assumption about Bob's client
- no assumption that Bob has pre-registered 
- no assumption of any particular trusted federation
- no assumption that the RS and AS are anything but generic UMA

All of these constraints together make for a bad user experience under any circumstances with or without technology. Shared door locks are no joy today when the apartment doesn't have a wired telephone line, or when the doors require Bob to have a $40 fob.

The user experience improves as we remove some or all of the 6 constraints. As far as QR codes and password less authentication, I don't think that's something we need to deal with in UMA.

Adrian


On Tuesday, April 12, 2016, John Wunderlich <john@wunderlich.ca> wrote:
Adrian;

This is a process for early adopters at best. Steps 1 through 9 sound like what early car enthusiasts had to go through to start a car: Magneto, Switch, Contact, Prime gas,…Crank the engine. If it doesn’t start return to the beginning. Cars still effectively do most of this, but it has been automated and put out of sight. I’m a geek and I find the process you outlined daunting. Until the process is as easy as putting a key in the lock and opening the door, ​it’s unlikely to have mass appeal. 

The big question for me is how to move the steps you’ve outlined out of band to something that is easier than what we currently do. For example - why can’t the building display a QR Code that Bob can scan with his phone. His phone is his authentication, and the QR code validates that he’s in front of the building.



Sincerely,
John Wunderlich
@PrivacyCDN

Call: +1 (647) 669-4749
eMail: john@wunderlich.ca

On 12 April 2016 at 18:24, Adrian Gropper <agropper@healthurl.com> wrote:
Here's how a shared door lock would work today:

Step 1: Bob approaches the shared door and sees a sign telling him how to access the building directory
2: Bob connects his phone to the local wi-fi access point
3: Bob types the URL of the building directory into his browser - the door lock RS serves up a directory page
4: Bob clicks Alice's link in the RS directory page - is redirected to Alice's AS
5: Alice's AS challenges Bob somehow - it could be that Bob has to enter his cell phone number, or open a WebRTC call with Alice - whatever
6: Alice thinks up an access PIN for Bob - enters Bob's cell phone number and PIN into her AS
7: Alice tells Bob the PIN - however she does that
8: Bob enters the cell phone number and PIN into the AS
9: The RS opens the door

Case A (LAN only): The sequence above mirrors what happens today when Bob talks to Alice and is "buzzed-in". The only difference is that Alice must sign-in to her AS to enter a phone number and PIN and Bob must enter the same two things into the AS. This is not a great user experience but it is needed because we took away the proprietary buzzer connecting Alice to the lock. The benefit is that Alice can decide when Bob's PIN must expire.

Case B: Add a WAN connection and an IDP that might or might not be trusted. Alice's AS asks Bob for his IDP and name https://onename.com/agropper . Alice's AS either accepts Bob's attributes automatically or it sends a text message to Alice with the link. Alice replies to the text message with yes and an optional expiration date.

I'm not sure what the challenge analysis document is.

Adrian


On Sunday, April 10, 2016, Eve Maler <eve@xmlgrrl.com> wrote:
Adrian, so far this looks like a use case (and an interesting IoT use case at that) -- but not quite a solution description, in that we don't know if it actually resolves #wideeco problems we've identified. E.g., the mechanism of providing claims works great in narrow and medium ecosystems already, but it seems to break down in wide ecosystems for various reasons.

Can you please start a new thread, and also be sure to describe which challenges in the challenge analysis document (and/or any other new challenges not previously discussed) your solution purports to solve? It's perhaps also worth noting that there are smart door looks and doorbell products on the market, if not ones with UMA capabilities; can we learn from what they do now?

(We'll probably want a new thread per solution area.)


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Sat, Apr 9, 2016 at 2:07 PM, Adrian Gropper <agropper@healthurl.com> wrote:
AI for discussion: Different patterns of Alice's AS and RS's accepting and providing federated logins? (Adrian)

I would like to champion a #wideeco solution called "A Lock to Alice's Shared Door" as follows:

I believe these 6 are the only distinct categories and I would hope that Alice's AS supports all of them if Alice is willing to take the time to configure them. Within each category, there will be various user experiences depending on what kind of technology Bob has in his pocket.

Adrian


On Fri, Apr 8, 2016 at 4:40 PM, Eve Maler <eve@xmlgrrl.com> wrote:
I've also done a little bit of suggested reordering of the roadmap priorities to account for the appearance of so many use case buckets in the first bullet in the list, and other realities; please see what you think. Essentially, we can't really consider Justin's proposals for #wideeco without also considering their #simplify impact, and some of their #IoT impact, but some other #IoT analysis will have to wait a bit longer. Also, we don't have any #security work on our docket at the moment, but more could arise at any time, and there's some constant legal-subgroup work being done. Etc.

Oh, and I've put the named people who I hope will take on action items directly on the cc list this time, to draw their attention to my request.

Happy Friday! :-)


Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl


On Fri, Apr 8, 2016 at 9:52 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Hi all-- The agenda for our call yesterday tried to summarize what I think is the most up-to-date list of ideas I've heard so far:

  • Examining solutions for wide ecosystem challenges (Eve's challenge analysis doc) – look at:
    • UMA-protected UserInfo? (various) [Mike]
    • Different patterns of Alice's AS and RS's accepting and providing federated logins? (Adrian)
    • "Multi-party" proposal? (Justin) (engages with #APIsec and #simplify use case buckets too) [also #IoT as discussed on Thursday]
    • AS requests claims and client does act_as Bob to send them? (Mike, James)
    • Alice's AS dynamically gets client credentials to Bob's claim sources? (various) [Eve]
    • Meta-suggestion: Should trust elevation methods be modularized? (James)
    • Others?

Can the people identified above please take action items to present at upcoming calls? If you're not clear on what this is about, or if you can't do this action, please let me know. Thanks!

And remember, we've got some upcoming "holes" in our Q2 WG meeting schedule. I've just deleted some of our Thursday meetings (Fridays haven't been impacted yet), with possibly a couple more to come. We've got some exciting work coming up, so let's try to press ahead with offline prep such as this.

Eve Maler
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl





--

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




This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


--

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/