W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2014

Secure Origins and Strong Authentication

From: Jeffrey Walton <noloader@gmail.com>
Date: Wed, 20 Aug 2014 08:41:38 -0400
Message-ID: <CAH8yC8nkcAZ=ubO3zbsLev_Y2sj5vhU9h6Na0TFDKHLE=vVwbw@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
>From "Proposal: Prefer secure origins for powerful new web platform
features", http://lists.w3.org/Archives/Public/public-webappsec/2014Jun/0222.html:

    In systems with 2-part principals, it is crucial to strongly
    authenticate both parts of the principal, not just one part.

I'm curious about what makes the authentications strong. In the web
app model, any authority can claim to certify a resource. I'm not sure
I would consider it strong, and I would probably consider it weak. I
would consider it weak because we can't differentiate between the one
true authority versus imposters (or the one true server versus an

In fact, when data sensitivity warrant, I often find that an
application has to be moved from a pure HTML/CSS/JS web app to a
hybrid or native application so we can ensure server authenticity and
channel integrity. We need a hybrid or native application so we can
access additional APIs, like native callbacks or delegates to provide
additional checking on the authority or server.

Personally, I would feel more conformable using "strongly
authenticated" only if we could tell the platform or the socket that
"this is the server we should use" or "this is the CA to use from our
private PKI". Alternately, the app could enforce it if the platform
provided the requisite information to the application. And a way to
verify it at the application level would also help instill the

This, of course, requires a trusted distribution channel, and we often
have it in a corporate environment. We *might* have a trusted
distribution channel from the various App Stores, but its not clear to
me if tricks like [0] have been completely remediated at the platform

Forgive my ignorance here.


[0] Apple fixes iOS App Store man-in-the-middle hole,
Received on Wednesday, 20 August 2014 12:42:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:06 UTC