[Auth] Trusted Displays
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 15/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 領域
- security
調査の方向性
Read the linked May 2018 meeting minutes and this issue’s authentication discussion. The payload names no code files, tests, or entry points; first establish whether the protocol has a decided approach to trusted-device identity and compliance. Done would require a clear, agreed scope, which this discussion does not provide.
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Bikeshed
- スター
- 115
- フォーク
- 21
- 平均マージ
- 5時間 2分
- マージ済み PR(30日)
- 2
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
w3c/openscreenprotocol のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 18/100
w3c/openscreenprotocol#380 ·
-
osp-application
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
w3c/openscreenprotocol#377 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
w3c/openscreenprotocol#376 ·
-
osp-application
難易度 2/5 1〜3時間 初心者へのやさしさ 55/100
w3c/openscreenprotocol#375 ·
-
osp-application question
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
w3c/openscreenprotocol#374 ·
w3c/openscreenprotocol の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
txn2/mcp-data-platform#2493 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
LearningCircuit/local-deep-research#8318 ·
メンテナーはふだん 1 日以内に返信
-
dependencies Haushalts-Admin schwere: niedrig Security
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100