I see this solving issues with untrained staff having to enter 802.1x configurations during enrollment.  It would definitely speed things up.  My dream addition to this would be including the option for multiple enrollment accounts to be specified in the json and then have a GUI to select which account to use.  

We discovered during setup of our initial fleet of Chromebooks in 2013, that using the same account for Enterprise Enrollment repeatedly on dozens of devices quickly gave us captcha challenges. Just another annoying (and random!) thing to type every time.

Our solution was to use multiple different Enroll accounts and alternate between them pseudo-randomly.

Is your suggestion based on similar experience, or the need to choose between multiple different domains to Enroll to?

We place chromebooks into different organization units in the Google directory (the user used to enroll can automatically place it in the correct location [first enrollment only]).

+Omri who was looking at this problem

+Enterprise/EDU folks since they now own the app

Over to max who owns the USB Enrollment feature

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/255647f594123b3df84abd5d969a6e8bee63919c

commit 255647f594123b3df84abd5d969a6e8bee63919c
Author: Tudor Brindus <tbrindus@chromium.org>
Date: Thu Jul 19 09:52:04 2018

installer: Add evdev-based user interaction utility

This commit adds an utility `evwaitkey` that can be used during
installation procedures to wait for user interaction (e.g. for physical
presence checks).

Example usage (waiting either for escape key code 1 or enter key code
28):

    $ evwaitkey --keys=1:28
    <user presses enter>
    28

Example usage in script:

    KEY_ESC=1
    KEY_ENTER=28

    if [ $(evwaitkey --keys=$KEY_ESC:$KEY_ENTER) -eq $KEY_ESC ]; then
      echo "Escape pressed"
    else
      echo "Enter pressed"
    fi

BUG=chromium:793878
TEST=manually tested on workstation and cave board

Change-Id: Ib2fb7b700913f582eac15b2e38d16e5b6eaafb15
Reviewed-on: https://chromium-review.googlesource.com/1134425
Commit-Ready: Tudor Brindus <tbrindus@chromium.org>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Amin Hassani <ahassani@chromium.org>

[modify] https://crrev.com/255647f594123b3df84abd5d969a6e8bee63919c/installer/installer.gyp
[add] https://crrev.com/255647f594123b3df84abd5d969a6e8bee63919c/installer/util/evwaitkey.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/62fb8871a546e0b41c8ae8afb7695b13ef808265

commit 62fb8871a546e0b41c8ae8afb7695b13ef808265
Author: Tudor Brindus <tbrindus@google.com>
Date: Fri Jul 20 03:12:51 2018

installer: Add evwaitkey utility to ebuild

CQ-DEPEND=CL:1134425
BUG=chromium:793878
TEST=package builds

Change-Id: Ic2316de19ace0528b9cc9457d7204198bb582644
Reviewed-on: https://chromium-review.googlesource.com/1135784
Commit-Ready: Tudor Brindus <tbrindus@chromium.org>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Amin Hassani <ahassani@chromium.org>

[modify] https://crrev.com/62fb8871a546e0b41c8ae8afb7695b13ef808265/chromeos-base/chromeos-installer/chromeos-installer-9999.ebuild

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/20be1cd50b8ff2a49c069c6884cebe07835d36ae

commit 20be1cd50b8ff2a49c069c6884cebe07835d36ae
Author: Tudor Brindus <tbrindus@chromium.org>
Date: Fri Jul 27 19:12:48 2018

vboot_reference: Claim space for OOBE autoconfig public key

This commit claims a TPM space for a 33-byte P256 EC
compressed public key used in OOBE autoconfig validation.

BUG=chromium:793878
TEST=make runtests; precq
BRANCH=none

Change-Id: I12bf8243ceb2a0029b015964ea7a2ae2f56bb080
Reviewed-on: https://chromium-review.googlesource.com/1149073
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>

[modify] https://crrev.com/20be1cd50b8ff2a49c069c6884cebe07835d36ae/firmware/lib/include/rollback_index.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/e4e3acc08884f8c8aefad06225ccf4b96968bec2

commit e4e3acc08884f8c8aefad06225ccf4b96968bec2
Author: Tudor Brindus <tbrindus@chromium.org>
Date: Fri Jul 27 19:12:59 2018

installer: Make evwaitkey exit only on full key up/down transition

This prevents the possibility that a user starts recovery with the
target keys pressed, holds them down too long until the acknowledgment
screen shows up, and then has the release events count as
"acknowledgment".

BUG=chromium:793878
TEST=manually tested on workstation

Change-Id: Iab353877e0dc3a8eff6459ae32c3c9d0373ca195
Reviewed-on: https://chromium-review.googlesource.com/1152236
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Amin Hassani <ahassani@chromium.org>

[modify] https://crrev.com/e4e3acc08884f8c8aefad06225ccf4b96968bec2/installer/util/evwaitkey.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/chromite/+/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83

commit 2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83
Author: Tudor Brindus <tbrindus@chromium.org>
Date: Tue Jul 31 23:37:09 2018

cros_oobe_autoconfig: Add chromite script for OOBE autoconfig population

This commit adds a chromite command `cros_oobe_autoconfig` that can be
used to populate the OOBE autoconfig section of a recovery image, as well
as modify the image to be "hands-free", i.e. require no user interaction
for rebooting after recovery.

BUG=chromium:793878
TEST=files exist under expected permissions after running

Change-Id: I9828f3ed61dce6a73921d0af9c4a5f1e496fda0d
Reviewed-on: https://chromium-review.googlesource.com/1124099
Commit-Ready: Tudor Brindus <tbrindus@chromium.org>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Amin Hassani <ahassani@chromium.org>

[add] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/scripts/cros_oobe_autoconfig.py
[add] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/scripts/cros_oobe_autoconfig_unittest
[add] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/bin/cros_oobe_autoconfig
[add] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/scripts/cros_oobe_autoconfig_unittest.py
[modify] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/cbuildbot/run_tests.py
[modify] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/lib/osutils.py
[modify] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/lib/constants.py
[modify] https://crrev.com/2d1c2ecd2d8c07e685010a1d53d16ab5883e9f83/lib/osutils_unittest.py

I'm thrilled to see motion on this bug, but if I'm reading the tea leaves and commits correctly, I'm afraid the proposed workflow is not a time-saver. In fact, it may amplify setup times by a large margin.

It seems that the proposed workflow is as such:
1: Create desired configuration
2: Apply configuration to USB recovery stick
3: Restore Chromebook via USB stick
4: OOBE is skipped, and desired configuration is used instead

When it comes to receiving and configuring large quantities of Chromebooks, spending multiple minutes on a Recovery workflow for each and every Chromebook more than cancels out any time savings. 

Manual setup using the pre-existing Chrome OS installation from the factory would unfortunately end up being faster.
Not to mention the sheer quantity of USB recovery sticks that would be required to do initial setup at scale.

For large school districts like mine, we've used programmable keyboard-masquerading microcontrollers to handle the majority of heavy-lifting for OOBE setup via timed bursts of Tabs, Spacebars, and other keypresses. Each Chromebook is touched and focused on fleetingly — just enough to insert the USB stick, and then remove it and close the Chromebook when enterprise enrollment completes. The entire process takes about 60 seconds, with only about 5 seconds of direct attention. This works well the majority of the time, but is not 100% reliable. That inaccuracy (as well as improving the experience for other institutions without the resources we have) was the impetus for the original bug report.

I DO see great use-cases for this workflow well into the Chromebooks lifespan. We have students and staff that we'd like to be able to restore a Chromebook on their own, but not be given the WiFi credentials.

My original request was for the factory-installed OOBE to grab its configuration a file from a plain old external USB device. The USB device would only be needed for mere seconds before it could be removed and used on the next Chromebook.
My inspiration for this workflow was Apple's Mac OS X Server automated setup from about 15 years ago (see Chapter 2 on page 21: https://www.apple.com/server/docs/Command_Line.pdf )

I appreciate what seems to be an interest in s secure and trusted path for this configuration information, but at this point in a Chromebook's life, it is the definition of a blank slate, accepting arbitrary input from whoever is in front of it anyway.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/ac2a99ac59fedc18704cc8d7ff14093019ffeeff

commit ac2a99ac59fedc18704cc8d7ff14093019ffeeff
Author: Tudor Brindus <tbrindus@google.com>
Date: Sat Aug 04 15:09:34 2018

installer: Add cros_oobe_crypto to ebuild

This commit adds the new `cros_oobe_crypto` utility to the ebuild for
chromeos-installer.

CQ-DEPEND=CL:1151889
BUG=chromium:793878
TEST=package builds

Change-Id: Ica1d7a8a39df715a1813967f06291a858f3825e7
Reviewed-on: https://chromium-review.googlesource.com/1152043
Commit-Ready: Tudor Brindus <tbrindus@chromium.org>
Tested-by: Tudor Brindus <tbrindus@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/ac2a99ac59fedc18704cc8d7ff14093019ffeeff/chromeos-base/chromeos-installer/chromeos-installer-9999.ebuild

re: comment #13 - often times, fresh-from-factory devices have images that are quite old. How do you ensure that the devices have the correct image on them? Or do you just enroll them and let them all individually update using the normal background update cadence?

Great point that there's a good use case for driving OOBE without forcing a recovery flow. +ahassani FYI

Our typical summer workflow involves enrolling anywhere from 800-4000 Chromebooks, which then trickle out in groups of 30 or so over two weeks during a class orientation. Students sign in, get situated with Google Drive, and learn the basic do's and don'ts of responsible ownership. By the end of each orientation, updates are ready to go.

Historically, we have not had an issue temporarily using an out-of-date factory image, and the time necessary waiting for an up-to-date image on each device, either through restore USB or after-enrollment updates, is too much given the limited resources and stacked calendar of our technical team over summer.

In the planned implementation of the OOBE autoconfig file, when a customized recovery image is generated, is the oobe_auto_config/data.config file readily accessible on the USB stick (i.e., on a basic ext4 partition without undue unpacking)?
If so, could OOBE check for the existence of that file on a both the local stateful partition AND a connected USB device? That would work fantastically in our use case as well.

In enterprise environment, including the recovery image on the USB drive is definitely useful since some devices can be couple dozens Chrome versions behind (Chromebits on Chrome 48 etc.) and you definitely don't want to wait until they are inside the corporate network for them to update.
But I'd also like the Certificate Enrollment extension (https://support.google.com/chrome/a/answer/6324985) to be included in the OOBE design considerations, since without it the OOBE won't be a viable solution for customers using certificates.