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

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Wed Aug 11 14:11:42 CEST 2010


On 11/08/10 05:24, Dave Longley wrote:
> On 08/10/2010 08:37 PM, 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.
>
> I'm not quite sure what you mean by segregation here. Do you mean
> different UI entry points for authentication? If so, the interfaces can
> be unified but I'm not sure how great the advantages of doing that are.
> I don't expect the user interfaces for creating/managing/using Web ID
> certificates to be so rigidly defined in the specification that there is
> little room for innovation in the field. If you mean there shouldn't be
> segregation within the specification then I think I agree. If you mean
> something else... I apologize but I missed it.

Sorry, I wasn't clear. I mean that you may end up with multiple 
categories of sites: those that support JS+Flash and those that don't.
As far as I understand, the target service (the one with the 
Verification Agent) needs to be tweaked to support JS+Flash. I suppose 
it's not as big a deal on the WebID provider side, since they could be 
made compatible with non-Flash WebIDs


>>> 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.)
>
> Unfortunately, I believe this is a security concern at present (security
> holes w/TLS-renegotiation). This can be avoided entirely by having the
> server instruct, via JavaScript, when the client ought to send a
> certificate and when it shouldn't. This gets around the current
> renegotiation security issues but still allows a user to verify the
> identity of the site they are visiting before having to send their own
> identity to it. That isn't to say that their certificate isn't safe for
> public consumption or that they can't opt out of sending a certificate
> via their browser UI and then reconnect after checking out the site.
> This just may be more tedious.

Of course, I'm just assuming that the new renegotiation should be 
implemented widely relatively soon. People who still support the old 
style should really turn it off (that was the default behaviour of IIS 
no so long ago, I'm not sure if it's been fixed since the last time I 
checked).

Just found this link, btw: 
http://www.microsoft.com/technet/security/bulletin/ms10-049.mspx
"The security update addresses the vulnerabilities by implementing RFC 
5746 and additional validation on SSL responses returned by a server."


>>> [...]
>>
>>>>> 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.)
>
> We might be miscommunicating. By "simple dereferencing" do you mean
> following the Web ID SubjectAlternativeName URL and confirming that the
> public key at the other end matches the one provided in the TLS
> connection? Or something less/more than this?

Yes, by "simple dereferencing", I mean verifying the WebID by getting 
the public key obtained from a GET on the WebID itself: the WebID (and 
implicitly its host) is the source of authority.


>>> 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.
>
> I wasn't suggesting that the key not be checked. I was suggesting that
> the Web ID provider can create any keys that they want to -- and they
> will still be checked and pass authentication. You are correct, however,
> that no third party will have verified that the Web ID URL, the public
> key, and a real identity have been properly matched together
> out-of-band. However, I don't believe that methods for accomplishing
> this are being seriously explored at this time (as part of the Web ID
> spec). I understand the usefulness in the future.

Indeed, you are right, it has not been explored much, but the easy way 
to start using the key information is for the target site (the one with 
the Verification Agent) to remember the public key of your previous 
visits, and possibly re-challenge the user for extra information if 
there's a mismatch. That's quite easy to do in principle and does 
require third-party signing for example.


>> This is the part that makes PKI difficult, more so than the technical
>> aspects of handling certificates.
>> [...]
>
> Understood. However, as it stands, I think Web ID certificates that are
> not verified by a third party offer the same level of security as the
> login systems that it was (as far as I know) originally conceived to
> globally replace.
>
> For instance, when I create an account on Amazon, I simply enter an
> email address and password. I can enter whatever information I want to,
> the only check might be that I own an email address somewhere on the
> web. When I try to use my credit card to purchase something, my credit
> card is checked by Amazon (via their merchant account/Visa/etc.) to
> ensure the information I entered is accurate. Amazon has direct access
> to my account information and all of my credit card information at this
> point. They could abuse that information without my consent.

Sure, but the problem is that you now have 3 parties involved: the user, 
Amazon and the WebID host. By concentrating your credentials into your 
WebID, this makes it an attractive target.
In addition, the legal agreements are between the user and Amazon. 
Having a WebID host in the middle makes the equation more complex.

(Arguably, you also have a 3rd party sometimes with e-mail password 
recovery.)

> If I were to log in to Amazon using a Web ID this would be no different.
> The only difference would be if the PKI were extended to the credit card
> gateway that checks the information I entered -- and if I were to sign
> that information using my Web ID private key. This would certainly
> enable a more secure web experience but I consider it far beyond the
> scope of the first Web ID specification/implementations. Of course, that
> doesn't mean I disagree with your points.

I'm not saying that you need to sign that information explicitly just 
yet, but at least keeping a record of the public key that was used, in 
case transactions are challenged at a later date. A bit like "verified 
by PIN" that you get when you pay in a shop with your card.

None of these mechanisms are 100% secure (even chip & pin), but leaving 
enough information for an audit is quite important, even if it's just 
the public key that was used at the time.


> That being said, I have no idea how people in the general public would
> go about (easily) getting their Web ID certificates signed by trusted
> third parties ... and I would fully expect there to be a cost associated
> with this that most people would find undesirable (at least at first).

We could set up the equivalent of CAs (to sign WebIDs/FOAF documents) at 
a later date. This will almost inevitably present similar problems to 
what existing PKIs are facing.
However, the advantage of the decentralisation of the WebID is that it 
provides more flexibility in which model may be implemented.
That's not an immediate goal, agreed.


> This is a little indirectly-related to Web ID, but there is a plan to
> have at least some measure of third-party verification of Web IDs as
> part of another specification that deals with micropayments, PaySwarm.
> The idea is that the PaySwarm Authorities (entities that manage
> financial accounts and handle credit cards) will have verified that the
> owner of the Web ID is a real-world entity (has a credit card and
> address that was verified by the PaySwarm Authority). After
> verification, the PaySwarm Authority would sign the Web ID (or relevant
> information therein) using its own private key. This doesn't prove that
> the Web ID owner is, in fact, the owner of the credit card (they could
> have stolen it and could happen to know the owner's address) but it does
> provide a little more trust than otherwise.

Sure, but by signing the WebID, you only vouch for the verification you 
made at the time regarding the user with that WebID, you don't keep 
track of how they had proved to you they were who they said they were. 
You need to sign the association between the WebID and its public key(s) 
for having a useful level of assurance.

Services with take payments based on the WebID will only make the check 
with respect to the WebID, but not with how you can check it.
It's a bit like having the government sign your passport with your name 
(your WebID), but not making sure you cannot easily change the 
photograph (the public key), or giving a reasonable opportunity for 
people to whom you show your passport to check that you haven't altered 
the photograph since the passport was emitted.

This may be fine for micropayments if the amounts are small enough, but 
that would be a problem is the value is higher.


> I just want to make sure that we aren't closing the door on some
> technology that might more easily get Web ID adopted in its early stages
> just because a much more secure technology (which requires far more
> collaborative infrastructure) may arise in the future. I don't yet think
> how things are currently implemented in the JS+Flash
> browser-UI-replacement is a step down (security-wise) from the login
> systems people are used to right now.

The problem is that if we allow for cases where the private key can also 
be controlled by a 3rd party, we lose any sort of proof associated with 
using the public key.
Perhaps the WebID document should contain extra information to reflect 
that loss of assurance.


My main point still is that, if we don't make suitable use of the public 
key but instead move away from using certificates, there's little point 
in developing WebID, we might as well try to extend OpenID with some 
semantic-web extensions.


Best wishes,

Bruno.


More information about the foaf-protocols mailing list