Another inverse #PhysicalWeb use case

By “inverse”, I mean where the Thing with the beacon wants to talk to the person, instead of the person to the Thing.

Here it is: doing the laundry.

1. I carry the dirty laundry to the washing machine. I have my cell phone with me, but in my pocket. My hands are full with laundry anyway.
2. I put the laundry and soap into the machine, and set the program I want it to run. I do that with the dials on the machine — much simpler than taking out my phone, even if the phone presented me with the right UI for the machine per the Physical Web Proposal. After all, the dials are optimized for exactly that.
3. When I’m done selecting the program, the washing machine asks me: would you like to be notified when the laundry is ready? I select yes.
4. Whenever the machine is done (and that may be a variable-length time, depending on program and machine), my phone rings and notifies me so I can deal with the clean laundry.

This can be made to work if the washing machine is able to detect the (close) presence of my phone while I am using the dials on the washing machine. That’s the reverse part of the standard physical web proposal. For example, my phone might first (passively) detect the washing machine, and when my phone decides (e.g. by running code from a URL associated with the washing machine, which was detected via the Bluetooth beacon) that I’m indeed setting the machine, it tells the washing machine to ask me. In my scenario, it’s the washing machine that asks about whether I want to be notified, not the phone, because I already have my hands on the washing machine dials, and my phone is still in my pocket.

There are some interesting identity, privacy, security and notification problems to be solved to make this possible, but I’d like to have this use case. The basically same use case applies in many similar situations: baking a cake, for example. Or being notified when the car wash has my car ready.