[Auth] Trusted Displays

[nigelcearnshaw]

These comments relate to the authentication discussion of the open screen protocol. In particular I wanted to comment on the trusted displays discussion from the last F2F meeting.

Presentation API assumes the device is trusted. device could be compromised or impersonated on the network … we need to verify the identity before exchanging information”

Agree, a password usually belongs to a user and is pre-shared with the service or is an ephemeral input to a pair of devices. It cannot help in determining whether the device is to be trusted with the presentation (e.g., won’t store and forward), that has to come from the manufacturer?

If the scheme incorporates a transition from PAKE to self-signed certificate it seems important to know that the cert is ‘honest’ and that the receiver isn’t subverting the process by presenting a compromised key. This is hard because if we have a means to certify a device compliance we should have incorporated it into the whole protocol anyway.

Trusted devices have to be certified as compliant by someone (manufacturer?) and somehow be recognised as such on the wire, e.g, have public + private keys and cert - with known root. This is difficult to coordinate. It may be that the device is generally known to be trusted within the LAN by nature of its model/spec and then has to be nominated ‘in the room’ by typing in a password, then authenticated as being ‘that device’ over the network using a PAKE protocol.

I suppose this is just observing that for robust end to end trust the integrity of the device is a critical factor.

[markafoltz]

Currently, attestation of the origin of the device or its manufacturer is not a requirement of the Open Screen spec, at least in its 1.0 incarnation. The focus is on preventing MITM of nearly all data exchanged via the protocol. However, standardizing a mechanism for attestation and "trust" can certainly be in scope for the future.

[markafoltz]

Discussion from Berlin F2F: https://www.w3.org/2019/05/23-webscreens-minutes.html#x26

The high-level takeaways/work areas:

1. Scope the problem by agreeing on the use cases for agent-to-agent trust. Handling of encrypted content is a primary use case that has been identified.
2. Devise an attestation protocol to allow one agent to prove something about itself to another agent.
3. Bring relevant parties together to agree on the necessary policies and procedures that will manage the necessary PKI(s). (Possibly in a different forum.)

We agreed this is currently out of scope for the v1 spec.

[markafoltz]

Attestation is an interesting area in this space. One benefit of interoperability with Matter is that it incorporates manufacturer attestation into its setup protocol. Products and users that care about attestation can build on top of Matter to get this ability.

I think building attestation directly into OSP could also have some benefits, but as I mentioned earlier is not part of its core scope.