- From: Nathan <nathan@webr3.org>
- Date: Mon, 08 Oct 2012 18:07:55 +0100
- To: Ron Garret <ron@flownet.com>, Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Anders Rundgren <anders.rundgren@telia.com>, Henry Story <henry.story@bblfish.net>, public-identity@w3.org, Read-Write-Web <public-rww@w3.org>
Ron Garret wrote: > On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote: > >> >> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren@telia.com> wrote: >> On 2012-10-05 20:47, Henry Story wrote: >> >>>> WebCrypto could very well become a better mousetrap than TLS CCA. >>> By WebCrypto you mean using javascript. That does not really change anything. >> It does because it liberates WebID from a scheme (TLS CCA) that in its current >> form is doomed as a consumer solution. >> >> TLS CCA is actually quite popular and useful for creating secure tunnels between >> servers. However, as a web solution for end-users TLS CCA has essentially not >> taken a single step forward since 1996! Well, the "underpinnings" have changed >> considerably but that doesn't help much since its "behavior" remains neanderthalish. >> The latter is presumably "by design". >> >> I'm surprised that you find the current key generation mechanisms useful. No major >> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in >> Chrome was also designed in the 90'ties. This is a very touchy issue since >> >> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html >> >> caused the PKIX chairs to remove me from the list! >> >> Anders, did you ever look at this? >> >> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html >> >> A full javascript solution to WebID including crypto libraries. >> >> May be interesting to this group. > > As long as Forge has entered the conversation I would also like to point to my own identity project: > > http://dswi.net/ > > DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome. You could decentralize it and make it stateless by: a) using a URI for a UID (which could point to the clients public key) b) removing sessions (makes it stateless) c) swapping nonce for the URI of the resource being requested (ensures user holds private key) d) adding an additional, optional, nonce (protect against replays, additional protection, spot checks etc) you could also: e) have optional origin bound keys f) factor out URI/UID identification, and have them as optional extras, this would allow specific origins to provide keys for clients which are associated with specific identifiers behind the interface. IMHO all of these protocols are pretty much the same at an abstract level, they're just mapped to different technology choices, and occasionally have some nice extras, and occasionally have a load of extras which aren't needed. Would be nice to define and standardize the intersection, instead of forcing a plethora of specs on the net/web which are fundamentally the same, only differing by forcing a particular technology choice, or optional extra, as mandatory. Best, Nathan
Received on Monday, 8 October 2012 17:08:53 UTC