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

Dave Longley dlongley at digitalbazaar.com
Wed Aug 11 17:01:18 CEST 2010


On 08/11/2010 08:11 AM, Bruno Harbulot wrote:
> 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

Ah, I understand you now. Yes, as of right now there is some minor 
tweaking. Fortunately, the tweaks are very simple and can be wrapped up 
in some code site admins can download and add to their site. When I said 
the JS+Flash option might only be available after the browser-UI option 
was attempted I didn't mean to apply it wouldn't be available at all. 
Sorry for the confusion :).

I was just commenting on how browser-UIs are currently implemented. 
Namely, if your browser has a Web ID already available it's probably 
going to show its own UI first, so the JS+Flash would only need to be 
shown if a Web ID was not selected.

However, I don't think it would be so harmful if Web ID providers only 
needed to support at least one of the two methods.

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

Good to hear.

>
>>>> [...]
>>>
>>>>>> 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.

All good points.

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

True. That was just a quick brain-dump of the basics going into the 
process; one would hope that the idea would be more robustly examined. I 
just wanted to let you know that your comments aren't lost on me. I 
think some measure of third-party verification is important and it will 
be part of some other related specifications. But, again, good point.

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

Agreed. But until Web ID includes public key tracking/out-of-band 
identity verification or similar mechanisms I think these 
(JS+Flash/other) technologies can help get it adopted. It may even be a 
better approach to do this in steps in order to get the general public 
interested and engaged in using the technology. The second step could be 
to improve security measures and push the power of Web ID into banking 
verification systems, etc.

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

I understand. But my main point is that we might not be able to do this 
all in a single step. It's a fairly large paradigm shift even without 
taking into consideration the changes in user interfaces that the 
average internet user has come to know.

>
>
> Best wishes,
>
> Bruno.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Phone: 540-961-4469



More information about the foaf-protocols mailing list