[foaf-protocols] Fwd: Re: WebID breakthrough - pure Javascript+Flash implementation

Kingsley Idehen kidehen at openlinksw.com
Wed Aug 11 10:35:11 CEST 2010


Bruno Harbulot wrote:
> Hi Dave,
>
> On 10/08/2010 21:37, Dave Longley wrote:
>   
>> We wouldn't expect all WebID providers to embed the Flash application,
>> only those that wanted to support this method of creating and managing
>> WebIDs. It is definitely a work-in-progress, but here's a basic overview:
>>
>> 1. A web service that supports WebID login (a Verification Agent)
>> provides the option to use a JS+Flash Web ID provider via a login web
>> page. This option might only be available if a Web ID certificate was
>> not already provided via a browser UI.
>>     
>
> I think we should be careful not to segregate between WebID providers 
> using JS+Flash and those without, both on the WebID provider end and on 
> the Verification Agent end.
> It's not clear to me what the outcome of this approach is for this.
>
>
>   
>> 2. The user, via their browser, enters the URL to their JS+Flash Web ID
>> provider or selects it from a list of supported/well-known Web ID
>> providers (ie: similar to OpenID).
>>     
>
> (You could also have a link to somewhere on the same site that has 
> re-negotiation enabled to get the cert from the browser.)
>
>
> Not entering the URI has been considered a feature of WebID. Henry's 
> always considered this as a big advantage over OpenID. (I'm not sure it 
> compensates for the pain of dealing with certificates, but that's 
> something about which Henry and I seem to disagree.)
>
> Let's bare in mind that, if we don't have that, we end up with a 
> scenario similar to the page that lets you choose between OpenID 
> providers on sites like StackOverflow (for example).
>
> Nothing wrong with that of course, but then it brings back the argument 
> as to why use WebID when OpenID already exists.
> (I'll come back on this when replying to the last paragraphs: it's about 
> using the keys.)
>
>
>   
>> 3. The server loads the Web ID provider URL in an iframe which displays
>> the Web ID provider's custom UI for selecting a Web ID. This UI can be
>> custom-tailored in a number of ways. It could be simple and just allow
>> you to pick a Web ID you've previously generated (via another page on
>> the Web ID provider's site). It could provide a button to generate a new
>> Web ID if one is not available. It could require a password to unlock
>> your stored Web IDs if you're on a shared computer. It could allow you
>> to generate a one-time certificate for use on a public machine, etc.
>> There are many possibilities here that might solve some current issues
>> with Web ID.
>>     
>
> Security-wise, let's be careful about iframes. More specifically, let's 
> not encourage anything like the mistakes of 3-D Secure (which, unlike 
> its name says, doesn't really protect the user but could be an easy way 
> of implementing phishing).
>
>   
>> [...]
>>     
>
>   
>>>> Flash doesn't have the concept of a keychain, AFAIK. We're using Flash
>>>> local storage to store the certificate. One positive side-effect of
>>>> using Flash is that your WebIDs are all accessible to any browser that
>>>> uses the Flash Runtime. So, Chrome, IE, Safari, Firefox and Opera all
>>>> share the same Flash local storage. So, if you create a WebID in Chrome,
>>>> the same WebID can be used in IE on the same machine.
>>>>
>>>>         
>>> I think there's a security issue there: I think with this model, your
>>> WebID provider not only controls your public key, but it can potentially
>>> read your private key, since it controls the Flash application which can
>>> then gain access to where the private key is stored. That's something
>>> that OS and browser-based certificate management prevents.
>>>
>>> On the one hand, it's not such a big deal since the WebID provider
>>> controls the public key anyway (and thus controls the ID).
>>>
>>>       
>> Yes, it is true that your Web ID provider can get access to your private
>> key. But, like you said, your Web ID provider controls your ID anyway.
>>     
>
> For usages that require more certainty regarding the ID, it's only part 
> of the verification.
>
> Remember that the verification by simple dereferencing is actually quite 
> weak. It's fine for a lot of things: more or less the same things as 
> what OpenID is used for, but it's not good enough when the stakes become 
> higher: typically, when it involves money and/or liability.
> When to require a higher level of assurance will be a trade-off between 
> usability, the value of what's protected and the liability of the 
> parties involved.
> (OpenID also faces this problem: this is why a number of big players are 
> willing to be OpenID providers but fewer of them are willing to accept 
> OpenID as a login system.)
>
>   
>>> On the other hand, it's a problem if you start doing verification by
>>> using a higher level of assurance that simple dereferencing, i.e. as
>>> soon as you start using the public key to verify that the user behind
>>> the screen is using the service, not just their WebID (which is a
>>> handle/identifier). Typically, if you start making things like payments,
>>> you'll want at least to store the public key (or fingerprint) of the
>>> user, so that, for auditing purposes, you can prove that it's not just
>>> the WebID that came to your site, but it's the person who had the
>>> private key for the public key at the time.
>>> This is useful if you assume that, regardless of whether the WebID was
>>> verified correctly, the private key for the public key you're presented
>>> with is only controlled by the user. If the WebID provider can
>>> potentially read (and retrieve) your private key, the you no longer have
>>> these guarantees.
>>>
>>>       
>> I believe that Web ID, necessarily, makes the assumption that any public
>> key that comes from a particular Web ID provider
>> for a particular URL is valid. What I mean by this is that the
>> assumption is that any information signed by the associated private key
>> should be considered authenticated using that public key. This means
>> that your Web ID provider can generate as many private and public key
>> pairs as it wants to without informing you that it is doing so. It can
>> then associate those keys with your Web ID URL since it controls that
>> URL. Therefore, your Web ID provider can make authenticated requests on
>> your behalf using a private key that it has kept all to itself anyway.
>>     
>
>
> Actually, no. That's the problem.
> Using the WebID only (without checking the key) is not going to be good 
> enough for services that involve financial transactions (except for 
> small amounts perhaps) or more risks (i.e. those for which you have to 
> be accountable somehow). You'll want additional security checks, for 
> example coming back to the same site where you've already been and 
> proven your ID out of bands with the same public key.
>
> This is the part that makes PKI difficult, more so than the technical 
> aspects of handling certificates.
> A traditional PKI will have a number of policies and legal documents 
> regulating how various checks have been made to bind the identifier to 
> the actual person. The certificate request process only binds the 
> key-pair to the (requested) identifier. Then, the users have to prove to 
> the PKI representatives how they relate to that identifier to be able to 
> have the certificate emitted. In some simple cases, it might just be a 
> e-mail address, but in more serious PKIs, you need to show an official 
> ID (passport...) in person.
> A service that requires this sort of level of assurance will only accept 
> certificates from a PKI for which the policies satisfy at least its 
> minimal requirements. Effectively, someone you trust, with a policy you 
> deem appropriate, has signed the association between the public key and 
> the identifier.
>
> When it comes to the world of WebID, this is something we can do by 
> having third parties sign the association between the public key and the 
> WebID, but this prevents instantaneous re-generation of the keys by the 
> WebID providers.
>
> Not checking the public keys at all can be quite a big deal in terms of 
> liability for all the parties involved:
>
>    - As a WebID provider, you could impersonate the identity of any user 
> hosted on your site. Even if you don't do it maliciously, you have a 
> certain liability to protect your users' identities against various 
> attacks on your side. (It could be problematic if financial transactions 
> were effectively verified by your site following an attack on the WebID 
> host).
>
>    - As a service (using a Verification Agent), it's hard to tell 
> uniformly what the level of service for the WebID provider is, how good 
> its verification of the binding between identifier and what it says 
> about person, etc. These services take a certain risk by allowing login 
> via WebID solely by dereferencing. If you go to your bank to withdraw 
> some money using some corporate ID card a priori unknown by the employee 
> as a form of ID, it won't work, but if you show your passport/driving 
> licence, it will work better. If someone else withdrew money from your 
> account and the bank had accepted some random unofficial ID as a a 
> proof, you'd certainly be entitled to make a claim for compensation.
> These things vary between countries and institutions, but as soon as 
> there's some money or responsibility involved, there will be a legal 
> aspect, and some audit trail will be required too.
>
>    - As a user, would you really want to use either types of services 
> above if they don't take adequate precautions? Typically, you'd only 
> want to put money into a bank that will verify that you are indeed the 
> person taking it out of it again.
>
>
> Having a 3rd-party assertion of the binding between the public key and 
> the WebID (with an audit trail to an actual person) is something that 
> can help address those problems.
> You could also envisage that you keep a record of the public key of the 
> person that made a deposit and let them withdraw without extra challenge 
> if they come back with the same key; if their key has changed, then they 
> should be challenged a bit more.
>
> This is only possible is the private key is really private. This can be 
> very tricky if we can't make the assumption that the WebID provider 
> doesn't have access to the private key.
>
> In addition to this (coming back to point 2 from the beginning), if we 
> don't make use of the public key, but just the ID, why not just use 
> OpenID? Sure, it doesn't have the semantic web and linked data aspect, 
> but that could probably be bolted-on via some special attribute.
>
> In short: not making use of the key and assuming the WebID itself is the 
> source of all truth is fine as long as no one takes real risks (e.g. 
> blog comments, various forums, ...); if we want to go further than that 
> (e.g. payments, ...), we'll need to use the keys as part of the 
> authentication, perhaps using 3rd parties that also certify what the 
> WebID itself says (including the information about the key).
>   

Bruno,

As per prior comment, my bank (Bank of America) already uses X.509 
certificates and Private keys to facilitate wire transfers (local and 
international). The only thing missing from their setup is the use of 
Subj. Alt. Name. Imagine what happens when I (or someone else) gets them 
to comprehend the virtues of simply adding a WebID to their existing 
setup :-)


Kingsley
>
> Best wishes,
>
> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>
>   


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 







More information about the foaf-protocols mailing list