dlongley at digitalbazaar.com
Wed Aug 11 06:24:25 CEST 2010
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
>> 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.
>> 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
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.
> 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.)
There may be several options that can deal with not having to provide a
Web ID provider URI. I believe Manu has mentioned XAuth as a potential
> 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).
I agree we ought to be careful -- and am not opposed to other solutions.
>>>> 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
>>>> 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
>>> read your private key, since it controls the Flash application which
>>> 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?
>>> 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
>>> 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
>>> 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.
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.
> 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).
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
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.
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.
In other words: Trusting your Web ID provider (which can be
fully-distributed ... it can be your own server, etc.) is not too much
to ask for Web ID at present, especially given that we don't want to
throw up adoption barriers. I can see how further security measures
could be required in the future where the private key is totally
inaccessible from your Web ID provider. This would remove the need for
some of the trust, but you would still need to trust that your Web ID
provider would not share any information you store on it in ways that
you did not authorize. Unless, of course, we're going to start storing
encrypted data ... but that opens a whole other can of worms.
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).
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.
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.
> Best wishes,
Digital Bazaar, Inc.
More information about the foaf-protocols