There is nothing like that first day when you bring your new baby home--it's a mixture of pride, happiness and nervousness. You secure your precious package carefully in your car for the drive home, your extended family gathers around to see the new addition as you carefully unwrap it, you then plug them into a wall outlet and then download the corresponding native application...
If you've added any type of smart device to your home, you know what a fiasco it is to connect to temporary wifi access points, flash your phone screen next to the device or type wifi credentials on tiny buttons. It's all complex, error prone and a mess.
Scott describes a vision of what he thinks the experience should be:
A shared discovery / configuration standard where a new device basically holds up its hand, announces itself to a hub device and then waits for clearance. The user experience would be as simple as getting an alert saying "This device, in this location, wants to do X, do you allow it?" At which point, once you just click, it's in.
While I agree with the desirability of the above user experience, I can't help but think about the necessary plumbing for it to be reached. Bottom line, I contend that the process of securely bringing a new device into the home has to be thought of as an 'identity operation'.
Think about the wording that Scott chooses for the consent step:
This device, in this location, wants to do X, do you allow it?
Identity, of both the device and home owner, is explicit in the above.
It is this device that is being authorized to perform certain actions, and not some other device already in the house or that might be added in the future. So necessarily, we must be able to distinguish one device from another when they are subsequently interacting with each other if we are to apply the authorization policy defined above.
The device likely has some identity given to it as the factory, maybe a MAC address, or some X.509 certificate. This factory identity may need to be exchanged for one specific to the home it is being installed in. How the device is identified within the house may not be how it is identified to cloud servers and applications.
Note that the device's location is interpreted as providing some assurance as to the device's bona fides; i.e., because it is presumed to be within the home (and brought there intentionally) the home automation hub is willing to enter in the initial discovery conversation and negotiation. This model protects against remote attacks, but not against wardriving.
The permissions are being assigned by you; i.e., the homeowner and not somebody else that might be in the house. There is, therefore, an implication of this authorization step requiring that you be authenticated as somebody who has the right to assign privileges to devices in the house; i.e., someone with the 'admin role' (thereby mitigating the above wardriving risk).
As the process of assigning privileges to new devices has definite security implications (if compromised, the device could be assigned inappropriate rights), the 'strength' of the authentication matters. And, given that this new device authorization step would happen infrequently and not everyday, it is likely justifiable to require a relatively strong authentication; i.e.; something better than a password for this step. The homeowner's phone will likely play a role here, facilitating a two-factor authentication in addition to likely providing the consent UI.
Consider an analogy. When an freshly hired employee starts a new job, they must be provisioned by IT with the necessary accounts and permissions against the applications relevant to their role. Some of those identities will be internal to the enterprise and used for distinguishing that employee from others for internal applications. But that same employee will almost certainly require access to externally hosted applications--either at partners or SaaS providers. The new employee has to be provisioned with accounts at these external clouds so that when they subsequently try to access those applications, they can be recognized and given appropriate permissions.
In the enterprise, a set of standard identity protocols have emerged over the past few years to facilitate interoperable:
Discovery of identity-server endpoints of business partners.
Provisioning (and critically, deprovisioning) of employee identities to applications.
Federated authentication of those employees to those applications without requiring additional credentials or passwords.
Authorization of API calls sent on behalf of those employees.
Exchange 'employee' for 'device' in the above and you've got a reasonable starting list of identity and authentication requirements for smart home devices.
Standards like SCIM, OAuth, and OpenID Connect were developed to enable the above identity operations for the Internet we have. But the authentication, authorization models and mechanisms they enable remain relevant for the Internet of Things that is coming.