Re: [webauthn-adoption] Agenda 2020-06-15

Hey all,

Sending my notes ahead of the meeting because of a scheduling conflict, I
hope to be able to join later.

We've been talking about TodoMVC <http://todomvc.com/> quite a bit in the
context of the wireframe project. For those unfamiliar with it, it has
multiple implementations of a simple todo app using different Javascript
frameworks, allowing for a quick comparison how one could be used in
practice.

In order to contribute a new framework, the app specification
<https://github.com/tastejs/todomvc/blob/master/app-spec.md> document is
the starting point for authors. It includes a starter template with two
dependencies: todomvc-common <https://github.com/tastejs/todomvc-common> has
utilities and todomvc-app-css <https://github.com/tastejs/todomvc-app-css> has
CSS. The reference implementation is written in Backbone and authors are
requested to keep their HTML as close as possible to this implementation.
Few other things of note:

   - Besides the reference implementation, there's a basic list of required
   functionality in the app specification
   - Code in the TodoMVC repo is MIT licensed unless specified otherwise.
   It seems most (if not all) example apps use the MIT license.
   - Unit tests have not been required in the past, but new contributions
   are requested to add these

One of the things we discussed in the calls was the need for unified
messaging to help educate end-users (whether to use "security key" etc). I
believe it'd help to have a similar look and feel in the browser as well to
support this. This would take more effort now but could pay off in the
future once we have more implementations being contributed, ensuring
consistency and no distraction of our goal because of the different ways
the examples look. For a reference implementation we could design our own
CSS but using a lightweight framework like Bulma <https://bulma.io/>
(single file which can be used without compilation or JS) is also an option.

There's also another aspect, whether we want to separate front- and
backends or have each example app be a complete whole where authors can
define the interaction themselves. If we want to mix front and backends we
would need to define an API. However libraries like Github's webauthn-json
<https://github.com/github/webauthn-json/> already take an
opinionated approach to this, and wrapping a library with a compatibility
layer to conform to another API would be more confusing than helpful I
think.

Cheers,
Bart


On Thu, Jun 11, 2020 at 11:05 AM Dominique Hazael-Massieux <dom@w3.org>
wrote:

> Hi,
>
> Here is a proposed agenda for our WebAuthn Adoption CG call on Monday at
> 5pm UTC (logistics at [1]).
>
> # Hosting of dev-oriented resources
> * ACTION: Nick to evaluate transfer of webauthn.guide to FIDO
> * ACTION: Andrew to evaluate hosting of webauthn.guide in FIDO and other
> deliverables from the group
> * ACTION: Luke to give information on webauthn.dev future
>
> # Wireframe project
> * License / CLA?
> * Naming?
> * [DONE] ACTION: Dom to create github org to host wireframe project in
> single repo
>   https://github.com/webauthn-adoption/
>   https://github.com/webauthn-adoption/webauthn-wireframe
> * ACTION: Bart to start discussion on how to frame the wireframe project
> (e.g. single unified UX or not) with pros/cons
>
> Let Nick and I know if you would like to discuss other items.
>
> Thanks,
>
> Dom
>
> 1.
>
> https://lists.w3.org/Archives/Member/internal-webauthn-adoption/2020May/0000.html
>
>