Re: keygen and client-certificates document available

On Dec 6, 2015 10:44 AM, "Mark Nottingham" <mnot@mnot.net> wrote:
> >
> > Does the TAG have consensus that <keygen> (and friends) is worth
> > replacing?
>
> Section 5 starts:
>   "The keygen element should be replaced by a new API better suited for
modern day application requirements."

My question was a different one. It was: is an improved version of
keygen-etc the right architectural fit for the web? It's this "modern day
application requirements" part that interests me.

> By "and friends", do you mean client certificates? That would be a much
broader discussion.

I meant the MIME types and the effects that downloading them cause. These
usually get rolled in, but I think that they are more important.

> >  It seems like there are plenty of approaches that can
> > support similar use cases, some of which have considerably more
> > momentum (see Fido for instance).  Is anyone signed up to do work on
> > this?
>
> What do you mean by "work" in this case -- FIDO obviously has a number of
people working on it (soon including folks from your fine employer, as I
hear it).

I mean "work" in the sense of activity that would potentially move toward
an actual deployment of the imagined replacement: writing specs or code.
And by "this" I mean the replacement for keygen.

> Generally, the TAG shies away from advocating for adoption of particular
proposals (outside the ones we generate ourselves, of course). That said,
we're happy to expound upon the architectural implications of various
things, and FIDO is on that list; see <
https://github.com/w3ctag/spec-reviews/issues/97>.

I am interested in learning the outcome of discussions on the various
architectural approaches. I'm glad to see that the general area is getting
some attention, it's definitely important.

> Ah, "informed consent" again.
[snip]
> We seem to be getting better at that.

Yes, I agree. Part of that is expecting a high standard. :)

> So, I'm sympathetic to the idea that even with permission, a cross-origin
correlator might not be the right thing here. However, we haven't got to
that, yet.

That's reassuring, but my reading of the statement is less nuanced than
that: cross origin is a goal, and it is ok to do that if you get permission.