- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 23 Feb 2012 08:00:47 -0500
- To: public-webpayments@w3.org
- Message-ID: <4F46387F.60405@openlinksw.com>
On 2/22/12 11:41 PM, Manu Sporny wrote: > On 02/22/2012 03:09 PM, Kingsley Idehen wrote: >> Great news! > > :) > >> One question: what happened to WebID support? I was about to have a >> play but could see any slot for authenticating and generating my >> account using my WebID . > > There are two forms of WebID that we looked at - the first was WebID for > login, the second was WebID for cross-site authentication. > > We are not going to support the first, at least, not in the near future. > This is due to lack of good browser support - the UX is fairly terrible > across all the browsers. Yes, but as you know, we can't control the browsers. Thus, why not simply have WebID as an authentication option. Let's not throw baby out with the bathwater here :-) > > Our company had proposed a non-native mechanism for browser-based > WebID[1], but the WebID community decided to not take that route. WebID > does not have any champions inside of the browser vendors. Additionally, > BrowserID has been proposed in its place with significant backing by > Mozilla[2]. But we have to play the options game, at least initially. The market will choose winners. You guys know enough about WebID to make it an option. Ditto BrowserID. I ensure all our solutions support WebID, BrowserID, WebID+OpenID, OpenID, Digest Authentication etc.. I encourage you to do the same en route to maximizing the payswarm early adopter pool. > > Based on these developments, we don't believe that WebID will gain any > traction in the near future (and thus the usability problem will not be > fixed). It will gain traction, but this is going to happen is a slightly different manner. Again, I encourage you to support it as an option. It goes hand in hand with Linked Data and the Read-Write dimension of the Web. > > The second was using something like WebID for cross-site authentication, > and that's where the Web Keys[3] spec comes in. Note that the demo we > released has the concept of an identity: > > https://dev.payswarm.com/i/manu That IRI isn't a Web scale identifier that provides a conduit to a profile graph etc.. The goal (as you know) has to be natural integration of this system into the larger Web. A IRI that resolves to a profile graph is essential for achieving that goal. Remember, WebID is just about a solution that leverages URIs, PKI, and Linked Data for verifiable identity, in line with AWWW. > > The URL above will list public payment accounts as well as public key > information in time (via RDFa and JSON-LD). So, the concepts that > survived from WebID include: > > * An IRI for an identity > * Public keys listed at that identity > * An IRI for each public key > * A link from the public key back to the identity that owns it > > This is enough to support a Web-based PKI scheme, which we will detail > more in the Web Keys specification, as time permits. Okay, that's more in line with my comments above :-) > > This information could be associated with a WebID, or it could be > associated with a BrowserID... we're going to stay agnostic on which > technology will end up being adopted into the browser in the end. Right > now, BrowserID has a much better UX story... and from what I read, it's > meant to be decentralized in time. As someone that's implemented BrowserID, WebID, OpenID, OAuth etc.. being agnostic is the only option for a dexterous system. The UX story isn't the key story though, it will always be about platform agnostic data access, representation, and integration. The UX is ultimately going to be incidental as UX itself is still driven by data :-) > > -- manu > > [1] http://digitalbazaar.com/2010/08/07/webid/ > [2] https://www.mozilla.org/en-US/persona/about/ > [3] http://payswarm.com/specs/ED/web-keys/2012-01-23/ > -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 23 February 2012 13:01:14 UTC