Re: Browser ID + all clientside JS WebID

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.

Received on Tuesday, 19 July 2011 20:10:25 UTC