Re: Same Origin Policy - Re: Agenda: <keygen> being destroyed when we need it

> On 16 Sep 2015, at 17:20, Ryan Sleevi <sleevi@google.com> wrote:
> 
> On Wed, Sep 16, 2015 at 3:08 AM, Graham Leggett <minfrin@sharp.fm <mailto:minfrin@sharp.fm>> wrote:
> On 15 Sep 2015, at 11:29 AM, Ryan Sleevi <sleevi@google.com <mailto:sleevi@google.com>> wrote:
> > Go to a site with a <keygen> tag in Safari or Chrome. See that it inserts a key in your (OS) key store.
> 
> That’s not how keygen works. The keygen tag has to be part of a form, and renders a visible indication of the key size.
> 
> https://drafts.csswg.org/css2/visuren.html#display-prop <https://drafts.csswg.org/css2/visuren.html#display-prop>
>  
> The end user has to actively click on something before the key is generated.
> 
> https://html.spec.whatwg.org/multipage/forms.html#dom-form-submit <https://html.spec.whatwg.org/multipage/forms.html#dom-form-submit>

Thanks Ryan. That helps the discussion move along: pointers to specs
that we can use to test the behaviour and think about the problem clearly
with you. Now we are in sync on this issue.

So part of the problem is of course that since the inception of `<keygen>` 
JS  has taken over and we end up with problems of which agent actually 
is responsible for which action.  This has corrupted the intended 
meaning of the <keygen> tag. ( I have been thinking in my work about 
the intention of keygen - well aware that the reality of it had not been
developed to the full )

In this case since the keystore is being affected and the user did not click
the button - it makes sense that the toolbar indicating insertion of the 
certificate should allow the user to decide whether to accept that action. 

Of course you'll answer: how does one get the user to understand what that
action means? 

This would require an intuitive Identity UI - based on a card and wallet 
metaphor perhaps -  which has to be consistent throughout the web 
and even the OS experience. An action of adding a certificate to such a 
keystore has to make it visible as such a card being added to the wallet. 
This is only needed if the card is to be used cross origin.  So for example
the current FIDO UI would not need that.

Addition of cards to the wallet should be sortable by origin in the wallet.
Origins that add a lot of useless cards to spam the user, should be 
deselectable by the user in bulk, and he should be able to either limit 
their use to that origin, or delete them, and refuse further ones from them.
It seems that making the origin of a card visisible is another important element
of this.

What this suggests is that the keygen tag during the process of calculating
the public private key should open an empty card and have some way of indicating
to the user that the action of producing one is in gear. This again is part of the
chrome/OS and should not be something the page can hide. 

This is the type of thing that is needed to put the user in control. It's along the lines
of the marketing that is going into fingerprint authentication making its way 
into phones.

This would be required whatever the type of support for the card. (X509 is just an
accident here ). From the User's point of view: the card UI is what is real, meaning
that better formats can change under the hood.

Hope this helps,

Henry