## 20160504 AK
----
 [[OpenID/CZ|česky]] | '''english'''
----
== OpenID Overview ==

[[http://openid.net/|OpenID]] is a decentralized system to verify one's online identity. While it is not intended to prevent spam or create a trust metric, it solves the single sign-on problem without relying on any centralized website to confirm digital identity. OpenID users identify themselves with a URI or XRI which they own, such as for a blog or a home page. Since OpenID is decentralized, any website can employ OpenID software as a way for users to sign in.

On OpenID-enabled sites, Internet users do not need to register and manage a new account for every site before being granted access. Instead, they only need to be previously registered on a website with an OpenID "identity provider", sometimes called an i-broker. They can also link to this identity provider from another website they own and log in using that website's URI instead, allowing them to connect their identity to their website. A website which accepts sign-ins from OpenID is called a "relying party" (see note below).

OpenID is increasingly gaining adoption amongst large sites, with organizations like AOL both acting as a provider as well as Wikipedia announcing that they will support OpenID. In addition, integrated OpenID support has been made a mandatory priority in Firefox 3 and Microsoft is working on implementing OpenID 2.0 in Windows Vista.

OpenID does not provide its own form of authentication, so it is not meant to be used on sensitive accounts (banking, e-commerce transactions, etc.), but if an identity provider uses strong authentication, OpenID can be used for all types of transactions.

 * Note that OpenID's "relying party" is not the same relying party as is expressed in CAcert policies nor the general case of CA/PKI policies.

== Providers ==

CAcert does not currently provide OpenID services, although it provides strong authentication in the form of client certificates.  These can be used technically to support an OpenID service.

CAcert does not endorse the following servers, and it should be noted that reliance on them may not be possible in a CAcert / certificates sense.

=== Certifi.ca ===

We are currently aware of only one OpenID provider that uses verified certificates to assure the identity of OpenID users.  That is [[https://certifi.ca|Certifi.ca.]]

'''Certifi.ca Walk Through''' 

The Certifi.ca site looks to see if you are using a certificate before displaying its home page.  If you are not using a certificate to log in, you will see a public information page that looks something like this:

{{attachment:certifi-login.png}}

If you are using a certificate to login to the site, you will be presented with your new (or existing) OpenID, like this:

{{attachment:certifi-login-new.png}}

The system will then challenge anyone trying to present themselves as you, by asking for both your certificate and passphrase.  This is a far more secure system than a basic OpenID provider.

Unfortunately, certifi.ca is somehow half-ready. Their connection to the identity is locked to a certain certificate. When the certificate expires, so does your identity.

== Cons ==

Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks.

While there are a lot of fancy claims made on the benefits of a de-centralized single sign on system, it will ultimately fail.  Only a handful of domains will be widely accepted, for the same reason people are running black and white lists for filtering mail, as open slather makes things too open to abuse.  In other words websites that accept all OpenID users will end up with blog spam, or worse.

OpenID is especially not useful for any sites where traditional passwords are used (not just sites which use passwords to prevent spam) due to lack of DNS security, any DNS hijacking that occurs could in effect steal identities.  This already occurs to a lesser extent with websites that email out passwords without attempting to verify the account truly does belong to the user requesting it, not just the user with access to the email account.

Even verified certificates like CAcert issues, can only solve some of these OpenID issues.

Writes Martin:
{{{
A critical factor with OpenID is that an implementation of login by OpenID does not give the web site any assurance that the user is who they say that they are.  As I understand it, this is true irrespective of whether a certificate is involved (as with certifi.ca) or not (as with my own OpenID server).  A Verisign OpenID gives no assurance, and of course neither does my own personal server.

So far as I know, there is a total disconnect between the OpenID mechanisms and the provider of the OpenID server - implementing the protocol gives no guarantee at all to the web site owner, and this is not something you can look for from OpenID.  Thus, adding a certificate into the mix makes no difference to the web site owner, since there is no way to query how the OpenID is being validated when the standard OpenID protocol is used.  The certificate will always be at arm's length and not visible to the web site.  The benefits of OpenID are totally for the user and not for the site owner.

The problem, as a user, with something like certifi.ca is that I do not know whether the server has sufficient safeguards to prevent my ID being hijacked by someone else.  Clearly, if CACert operated a certificate based server using a subdomain of cacert.org I would not have that doubt (or not enough to worry about it!).  The gain for a certificate based server over using my personal server would be the avoidance of a password login on the personal server.
}}}

== Opportunities for CAcert ==

Andreas writes:
{{{
the certificate gives openID somehow the credibility, makes it reliable. - Keep in mind, we as CAcert.org Community Members or / and Assurers are the only one, who make the bridge between reality and virtuality. Due to the face to face assurance, thus to the Web of Trust we are in the position to "say, yes this OpenID with certificate belongs to a real person
}}}

== What should CAcert do? ==

There appear to be three general approaches.

 1. CAcert to operate a centralised reliable OpenID server itself.
 1. Establish the conditions by which people can do the OpenID thing in relation to CAcert.
 1. Null case:  do nothing and watch and observe.  See where the chips fall, let the market figure it out.

=== Operate a Server ===

What are the pros & cons of operating a server in a centralised fashion?  Pros:

 * users can rely that the data is more or less secure, as secure as other CAcert servers.
 * the message is pretty simple, users can assume the same reliance framework.

Cons:

 * CAcert is likely to only operate one server, which might be a bit limiting.  There may be viable options out there that are crowded out.
 * Why should we waste good resources on something that can be done by others?  Are we a one-stop shop for everything that's cool today?
 * does a single server scale up?

=== Establish the Conditions ===

==== CAcert client certs, or? ====

According to Martin above, there is no reliable relationship at the tech level between a user of OpenID (webserver or client user) and the use of a certificate issued by CAcert.  So what might be interesting is to establish at the policy level something like:

|| An OpenID server should clearly express whether it is '''only using client certs from CAcert''' or whether it is hybrid arrangement. ||

A more extreme form of that would be to simply state that:

|| An OpenID server that uses client certs from CAcert must not take any other form of user authentication unless it is equivalent ||

Or somesuch.  The above is proposed more as a thought experiment.

==== Reliance ====

Another issue is the nature of reliance.  The mere fact of taking a certificate is uninteresting.  But taking a certificate and then making a claim to someone else is an act of reliance;  only members are permitted to do that.  So as a likely consequence of this, only members can operate an OpenID server.

We can go one of two ways here.  Either open it up:

|| Non-members can operate an OpenID server under conditions set out in XYZ ||

Or close it up:

|| Only Assurers can operate OpenID servers for other people. ||

This is for thought experiments.  Because of the nature of the reliance debate, something is necessary here, otherwise the unwitting operator is likely to find themselves at the wrong end of an Arbitration one day.

=== Do nothing ===

In practice, this is what CAcert is doing right now.  That's primarily a reflection of the absence of clear direction.

It is clear that we could run a server.  But the vocal proponents in favour of this option have not been able to answer the above questions, and the suspicion remains that the whole OpenID thing is just another bandwaggon.  If so, there is no particular need to move fast.

It is clear that we could establish a policy.  But not clear what the policy should be.  Until we can get some information on the risks & rewards of the choices above, the existing policies should remain in place because they were well-thought out, and they protect all the members.

This chapter in this wiki page is an attempt to move the debate forward.

== Competition to OpenID ==

The competitors to OpenID include:

 * [[ClientCerts]] which is CAcert's natural territory.
 * infoCard was the third in a series of experiments by Microsoft.  It might be "out of date" now because it tied is fortunes to Vista, which didn't work out.  Is it promoted in W7 ?
 * username + password
 * [[http://oauth.net/|OAuth]] is a protocol for API authorisation (not a "service" like CAs).  See [[http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-architecture/|OAath's security architecture]] and [[https://dev.cacert.cl/wiki/birdshack/Security|Birdshack's view]].


----

 . CategoryAssurance