RE: Browser ID + all clientside JS WebID

The webid group long had their own assertion format, a trivial signed redirect querystring. ONe authenticates using the webid protocol to one agent (perhaps known as an IDP), which does "token converstion' changing the clietn cert _ lookup of foaf card into a trivial signed assertion. Using browserID to do this transformation... is a obvious win-win. I dont think anyine in the webid community is particularly tied to the (trivial) signed URI convention. Obviously, the asserting party (having just done webid validation) can ALSO do emial-verification, should it wish. I AM willing to buy into the value of yet another blob format (signed json, this year). Without any doubt, the W3C in the xml-dsig (and OASIS in the application xml-dsign to signed SAML requests for websso and web services), made things really complex. Arguably, they did a worse job than the ASN.1 group did, back in 1986, doing the same thing. Since lots of scripting sites are now just doing trivial coding to accept such XML signed tokens (ignoring most of the security rules, and doing trivial string parsing for the attributes, sent over SSL), one might as well go downmarket FORMALLY, and have trivial signed blobs, of serialized objects. If we are going to go low end, we might as well have standardized low-end. signed SWT vs sgiend JSON? might aswell be JSON, for max interoperability, since lots of developers struggle to parse XML, even 10 years in.
 > Date: Tue, 19 Jul 2011 21:09:07 +0100
> From: nathan@webr3.org
> CC: ben@adida.net; kidehen@openlinksw.com; public-xg-webid@w3.org; msporny@digitalbazaar.com; henry.story@gmail.com
> Subject: Re: Browser ID + all clientside JS WebID
> To: public-xg-webid@w3.org
> 
> Nathan wrote:
> > Ben Adida wrote:
> >>> Generally speaking it seems at a non technical level, that BrowserID is
> >>> a nice abstraction layer on top of WebID, that makes it more user 
> >>> friendly.
> >>
> >> Right, at a non-technical level, but if you dig into the technical 
> >> details, the big difference is that BrowserID delivers an assertion in 
> >> the application layer, while WebID delivers it in the network security 
> >> layer.
> > 
> > question: if a domain isn't allowed access, at what point in the 
> > procedure does this take effect? before or after the assertion is sent 
> > to the rp/verifier?
> > 
> > scenario:
> > PublicKey storeWebID('http://we....');
> > string getWebID();
> > 
> > storeWebID takes a URI input, associates it with a keypair and returns 
> > the public key.
> > 
> > one adds the public key to their personal profile located at webid-uri 
> > (or has a script to do it w/ a password verification or some such)
> > 
> > getWebID pops up a dialog that asks them to select a webid uri, after 
> > selecting it, it signs it with the private key associated with it, gets 
> > the public key from webid-uri, verifies the signature, if cool it 
> > returns the webid.
> 
> that decouples it from TLS, but in fact, with just the current webID 
> spec all you need i an verifier, you'd simply call getWebID which would 
> contact say https://verifywebid.org/verify, which would request a clietn 
> side cert automatically with current browser functionality, user selects 
> cert to present, verifier returns back profile in json along with webid. 
> job done, even simpler, and allows the webid to be used outside of the 
> browser too.
> 
> Also, we discussed months ago about verifying email addresses, a 
> verifier service could provide this functionality easily, it's just 
> another assertion to get returned by them to the requesting client.
> 
> Unsure what benefits browserid brings here, it seems more constrained 
> and has less functionality / extensibility.
>