[Extra] client-id next steps - let's find them a home

[Bron Gondwana <[e-mail]>]

We discussed draft-yu-imap-client-id in today's meeting, and while we
came to the conclusion that it wasn't a document for the working group
to adopt, the problem it's trying to solve is something which the IETF
could help with.
Ned's comment in jabber that didn't make it into the discussion was
something like, it's a cookie, just one the client creates.  That's
pretty much it.  It's basically there are an input to the calculation
that every server has to make on every connection "how much do I believe
that this login is from who it says it's from", or at a more meta level
"how trustworthy is this connection and much do I want to obey its
requests".
At the most trivial level, that's what authentication is - the username
and password (or whatever) gives the server sufficient trust in the
other end of the connection that it allows access to (and maybe
modification of a subset of resources, correlated by the username used).
A general cookie-like "this is a device I have communicated with before"
as an additional input to the server's decision making would be welcomed
by services who see stolen passwords as a common fraud problem, so there
would definitely be appetite for this kind of work.
The open question really is "is this work better suited to a different
group and potentially a different area", and if so "can we help the
authors find that area".
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]