New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 769631 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
█ ke...@intel.com
engedy@chromium.org
reillyg@chromium.org
kpaulhamus@chromium.org
█ piperc@chromium.org
jdoerrie@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 780078
Blocking:
issue 612328



Sign in to add a comment

Device Service: Servicify U2F

Project Member Reported by blundell@chromium.org, Sep 28 2017 
It's unclear whether //device/u2f should be inside or outside the Device Service. We need to resolve that and then execute on the resolution:

(1) If inside, servicify it and move it into the Device Service.

(2) If outside, change its interaction with HID to occur via the Device Service and find a logical long-term home for it (as we're looking to eliminate //device as an end goal of the Device Service).

Ke He has a CL up for (2) if we go in that direction: https://chromium-review.googlesource.com/c/chromium/src/+/667801.

Comment 1 by reillyg@chromium.org, Oct 2 2017 

Summarizing my conclusion from an earlier discussion with kpaulhamus@,

To prevent blocking work to add BLE support to //device/u2f update it to use the HID Mojo service and keep it in the browser process. When Bluetooth is moved to the Device Service U2F can be moved as well and return to consuming HID via C++.

A component of WebAuthN must run in the browser process so that it has trusted access to knowledge about the origin a frame is displaying but the core implementation of the protocol for communicating with devices can and in my opinion should be sandboxed to the device service.

Comment 2 by blundell@chromium.org, Oct 4 2017

Blockedon: 612319
Cc: ke...@intel.com
Owner: ----
Status: Available (was: Started)
Summary: Device Service: Servicify U2F (was: Device Service: Determine whether U2F is inside or outside and execute on it)
SGTM. Changing this bug to be about servicifying U2F. As described in c#1, this project is blocked on servicification of Bluetooth, and when this project *does* happen, we should change U2F back to talking with HID via C++ instead of across the Device Service Mojo boundary.

Comment 3 by blundell@chromium.org, Nov 7 2017

Components: Internals>Services>Device

Comment 4 by jdoerrie@chromium.org, Dec 6 2017

Cc: jdoerrie@chromium.org

Comment 5 by blundell@chromium.org, Mar 5 2018

Blockedon: -612319
Cc: -ke...@intel.com engedy@chromium.org
Based on offline discussions, we're changing course and *not* blocking servicification of U2F on bluetooth s13n. We can servicify u2f, add a direct dependency on //device/bluetooth, and then in the long run //device/bluetooth will itself be brought into the Device Service. Balazs/Kim, is there a bug that we can block this on for the feature work currently going on in //device/fido that we want to complete before starting s13n of U2F?

Comment 6 by blundell@chromium.org, Mar 5 2018

Cc: ke...@intel.com

Comment 7 by engedy@chromium.org, Mar 5 2018

Blockedon: 780078
►

Sign in to add a comment