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

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Wed Aug 11 02:37:21 CEST 2010

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 

   - 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).

Best wishes,


More information about the foaf-protocols mailing list