- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Wed, 29 Jun 2011 14:34:03 +0200
- To: Henry Story <henry.story@bblfish.net>
- CC: "public-identity@w3.org" <public-identity@w3.org>
On 2011-06-29 13:19, Henry Story wrote: > > On 29 Jun 2011, at 11:07, Anders Rundgren wrote: > >> On 2011-06-29 09:21, Henry Story wrote: >> <snip>> >>> It would be great to have provisioning of such hardware devices be as easy as simple >>> keygeneration in a browser. >>> >>> I have heard of the keygen2 proposal, >>> http://webpki.org/auth-token-4-the-cloud.html >>> but I am not sure what other use cases more the advanced keygens are trying to solve - >>> probably because I have not yet hit those limits myself. >> >> A very basic bank-requirement that isn't met by current browser-vendor >> "keygen" solutions is the ability defining a PIN to a key. >> >> In a typical WebID scenario a PIN would probably be a user option but in >> the bank-world it is the bank that unilaterally sets the policy. > > The key that is sent to the server is a public key, so it is of no use > without the private key. Yes. > The keychain on the users computer is protected > with a password usually, or the cryptokey is. Yes, but does the bank know that? With the current schemes they have no information about how a key is stored or protected at all. If you get the key *physically* from the bank all is good and well but then you don't need "keygen" because the key is already deployed and so is the PIN. > The thing to protect after all is the private key, and that should not leave the device. So I am still not sure I understand this requirement. See above and think "Virtual Bank Card". >> A good "keygen" system should support different policies. > > You mean it should allow the user to tell the server what types > of certificates are needed in return via some information sent > in the keyrequest? > If so can that not easily be done by adding extra attributes in forms? > > If the aim is to make the attributes in the forms machine readable, so that a robot would know by inspecting a form how to fill it out, then there are two simple solutions: > - hardcode form parameters but specify the post end point to be of a certain type: a type where attributes have a well defined meaning. This is what we do in the pingback protocol http://bblfish.net/tmp/2011/05/09/ > - develop an RDF markup for forms (I think there are some) > > The nice thing is that the above don't need changes to the browser. > > But I am probably missing something here. Yes, in a bank-world it is the bank that tells you what you need. You apply for a "card" and then get it in the way the bank thinks it should be which may be physical or virtual where I target the latter. > >> A 10-pass protocol for setting a PIN may appear "slightly" over-engineered >> but KeyGen2 does a few other tricks as well :-) > > What I'd love is at least for > > - keygen to be implemented on all cellphones, for better UIs. > - Better UIs. Some are really too technical, such as Opera's which on many other respects is really good, as it gives the user to choose between way too many key strengths. Yes, for bank, telco, enterprise and government keys key strength, algorithms, PINs, etc etc is not in any way controllable by the user. If your container can't deal with a certain requirement you won't get any key at all. > - seamless integration with cryptokeys, so one can use one's cryptokey to start one's car and use it in an internet café. Yes. Anders > > Henry > >> >> Regards, >> Anders >> > > Social Web Architect > http://bblfish.net/ > > >
Received on Wednesday, 29 June 2011 12:34:54 UTC