Re: [Mathmesh] Alternative approaches to Web passwords

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 21 November 2019 08:06 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6100120822 for <mathmesh@ietfa.amsl.com>; Thu, 21 Nov 2019 00:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlDWgDgeiHu3 for <mathmesh@ietfa.amsl.com>; Thu, 21 Nov 2019 00:05:59 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3609A120048 for <mathmesh@ietf.org>; Thu, 21 Nov 2019 00:05:59 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [IPv6:2001:67c:370:128:8c67:35ff:fe03:4a21]) by relay.sandelman.ca (Postfix) with ESMTPS id 9C2F51F450; Thu, 21 Nov 2019 08:05:57 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id E0EEE1142; Thu, 21 Nov 2019 16:05:57 +0800 (+08)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Phillip Hallam-Baker <phill@hallambaker.com>, mathmesh@ietf.org
In-reply-to: <CAMm+LwhaxoWqONv6neYYzf+7=R3hkbuTwR52y9kz57WG==U+Vg@mail.gmail.com>
References: <CAMm+LwhaxoWqONv6neYYzf+7=R3hkbuTwR52y9kz57WG==U+Vg@mail.gmail.com>
Comments: In-reply-to Phillip Hallam-Baker <phill@hallambaker.com> message dated "Tue, 19 Nov 2019 10:38:06 +0800."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 21 Nov 2019 16:05:57 +0800
Message-ID: <5487.1574323557@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/wh0zs5Tkraa7rPNXb9yPkrVFWFc>
Subject: Re: [Mathmesh] Alternative approaches to Web passwords
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2019 08:06:02 -0000

Do you mean:
   Alternative approaches to Web passwords
or:
   Alternative use cases than Web passwords
   ??

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
    > 1) The Mesh Password Manager is not intended to be limited to the Web
    > Browser application and that is probably not the early adopter area.

I think that it's worth recasting this slightly.
The problem is not about synchronizing passwords between browsers on
different devices, but between enabling access between devices with full user
interfaces, and those with limited user interfaces.

I write access rather than passwords, because I believe that more and more
the "login with X" is really important.

My TV's netflix would like to login with facebook, but I really don't want my
facebook password to be simple enough that I'd be willing to type it in with
the TV's <->^V remote control keypad.

While netflix could (and maybe they do) solve this by having me login to
facebook and connect my account up from my laptop or phone, and then store
the resulting OAUTH token in their cloud, (and there are dozens of reasons
why this model is less desireable), the problem is that it does not
generalize to arbitrary services and arbitrary devices.

There are extensions (plugins) to many browsers that will let you send a URL
to your phone.  This usually uses the infrastructure of the phone makers. I
don't know if it works cross-browser/phone. (So Chrome->Android works, and I
imagine Safari->iPhone works, but I don't know about the other combinatorics)

I am imaging a system where it could be common to be able to send
authorization to your TV/fridge,ec.  We need to this in a standard way
because we don't expect all our IoT devices to run the same browser as our
desktop, nor for every member of the household who wants to do this to have
to run the same browser.

As a simple and direct use case, if I had a fridge with an LCD
display (I think you have one Phill) then it would be nice if the detailed
(not just public) calendars for all the members of the household were visible
on the LCD.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-