Bruno.Harbulot at manchester.ac.uk
Wed Aug 11 02:37:21 CEST 2010
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
(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
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
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).
More information about the foaf-protocols