Re: keygen and client-certificates document available

Hi folks – as interesting as this discussion is, I'd like to try to focus
some attention back on the document that Travis produced. We are trying to
assemble some specific feedback there via our issues register in Github (
https://github.com/w3ctag/client-certificates/issues). If you've got
specific issues on this document, can I please ask you to open an issue
there.

Thanks,
Dan

On Sun, Dec 6, 2015 at 10:57 AM Martin Thomson <martin.thomson@gmail.com>
wrote:

> 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.
>