• http://testingsaas.blogspot.com Cordny Nederkoorn

    Hi Francisco,

    great initiative.
    A good draft with clear explanations of your proposal to build in privacy-enhancing technologies into the fabric of the web: TLS and HTTP.
    ‘Sounds’ like a good way to exclude 3rd parties from the id.-information the end-user wants to share with a third party.
    TLS is already the protocol to secure the connection between web browser and web server, so why not extend this protocol with a resource for privacy enhancing (PE)credentials.

    On thing though, I’m no TLS-expert, but I’m always wary of a Man-in-the-Middle or Man-in-the-Browser Attack (see my blogs about it)
    I know, you describe encrypted Client-Initiated Exchange, but during Server-Initiated Exchange I read:

    ‘An issuance protocol can be used to replace a credential present in the browser…
    Such a nomenclature can be achieved by using URLs as names’
    (draft paper, p.5)
    Isn’t using URLs here a security risk?

    Account login and session tracking gives, IMHO, too much power to the relying party (RP)by excluding the CA as third party (this is now done by RP)
    I don’t know if this is a good idea, we have CA’s to account for that Digital Certificates certifies the ownership of a public key by the named subject of the certificate, and therefore is a trusted 3rd party, trusted by both end-user and RP.
    OK, it only uses a PE credential instead of a PKI certificate, which could enhance privacy, but still , IMHO,there is too much power for the RP here. Who says the enduser the login certificate is not tampered? I don’t know if NSTIC doesnt’t want a NSTIC accredition authority here?

    That’s it for now, I have more, but I’ll deliver them in a later post.

    Francisco, I hope you can answer my questions and hopefully even more people want to join this discussion.
    I think it’s a good initiative, but it has to be deepened and perhaps even visualized by diagrams etc. That visualizes your ideas more.
    Thank you for sharing your proposal.

    The use cases are sufficiently described (details, as already said, are still necessary!!)

  • Francisco Corella

    Thank you very much for your comments.

    URLs are normally used to access Web resources, such as documents. But they can also be used to name things, people, or concepts. For example, both OpenID and WebID use URLs as user IDs. This takes advantage of the domain name system to avoid name collisions. A URL used as name may or may not also be used to access a Web resource.

    Examples of credential names could be http://dmv.ca.gov/drivers-license.html and http://dmv.ca.gov/identification-card.html, referring respectively to the driver’s license and the identification card issued by the California Department of Motor Vehicles. Pointing the browser to these URLs could retrieve metadata about the credentials, but doesn’t have to retrieve anything at all.

    URLs used as names should probably be called URIs rather than URLs, but the terminology has evolved and is still evolving: see RFC 3305, RFC 3986, and http://info-uri.info/.

    Hopefully it’s now clear that using a URL as a name cannot possibly introduce a security risk.

    In Section 3.1 we used the term “login certificate” to refer to a certificate that is issued by the relying party itself when the user registers, and submitted to the same relying party, as a TLS client certificate, when the user logs in. A login certificate is used by itself in some of the use cases in the paper, and in conjunction with other credentials in other use cases; there are also uses cases where login certificates are not used.

    A login certificate is equivalent to a username-and-password credential, except that it provides much more security. When you log in to a relying party with a username and a password, your knowledge of the password tells the RP that you are the same user who earlier registered with the username. Similarly, when you log in with a login certificate, by demonstrating knowledge of the associated private key, the browser proves to the RP that it is the same browser to which the site issued the certificate. There is no need for a third party to make an assertion about the user, because all the RP wants to know is that it is communicating with the same user who registered.