Identity 2: OpenID Tutorial with CA bonus

Background for OpenID

OpenID is an open federated identity standard for consumers. It allows individual Single Sign-On (SSO) to "relying party" sites from an OpenID provider usually either

• an email provider or

• social network.

Large OpenID providers such as Google and Yahoo! issued OpenIDs to their users. OpenID is one of few federated identity standards that enable SSO without a pre-existing relationship between the identity provider and the relying party. This helps scalability.

The current OpenID version is 2.0

OpenID AB/C merges two standards: OpenID Abstract Binding and OpenID Connect, and is under construction. OpenID 2.0 is only profiled for the lowest level of assurance in NIST 800-63.

Hopefully, the next generation of OpenID will be more capable.

How It Works

OpenID is a passive protocol, using browser web redirections to communicate between the relying party and the OpenID provider. OpenID does not construct a token containing security elements, but rather uses HTTP query string or Form POST to represent separate fields, reducing complexity. OpenID specifications cover discovery and authentication.

OpenID specifies discovery mechanisms that allow a user to inform the relying party of the preferred OpenID provider, including a URL or email address.

Benefits

OpenID was designed to be simple and lightweight. It is easy to read and understand the core protocol. There are OpenID libraries available for many languages, which help relying parties. If used with security best practices, OpenID can be a versatile protocol.

Via https://www.pingidentity.com/resource-center/openid.cfm

Certification Authority Bonus Supplement

Symantec offers three distinct classes of Certificates, with each class providing specific functionality and security features corresponding to a specific level of trust:

(i) Class 1 Certificates. Class 1 Certificates offer the lowest level of assurance and should not be used for authentication purposes or to support non-repudiation. They do not provide proof of the identity of the Subscriber. Class 1 Certificates are appropriate for digital signatures, encryption, and access control for non-commercial or low-value transactions where proof of identity is not necessary.

(ii) Class 2 Certificates. Class 2 Certificates offer a medium level of assurance in comparison with the other two classes. Class 2 Certificates can be used for digital signatures, encryption, and access control, including as proof of identity in medium-value transactions.

(iii) Class 3 Certificates. Class 3 Certificates provide the highest level of assurances. Class 3 Certificates are issued to individuals and organizations for digital signatures, encryption, and access control, including as proof of identity, in high-value transactions.

(a) Class 3 individual Certificates provide assurances of the identity of the Subscriber based on the personal (physical) presence of the Subscriber to confirm his or her identity using, at a minimum, a well-recognized form of government-issued identification and one other identification credential.

(b) Class 3 organizational Certificates may be issued to devices to provide authentication; message, software, and content integrity; and confidentiality through encryption. They provide assurances of the identity of the Subscriber based on a confirmation that the Subscriber organization exists, that the organization has requested the Certificate Application, and that the person submitting the Certificate Application on behalf of the Subscriber was authorized to do so. Class 3 organizational Certificates also provide assurances that the Subscriber is entitled to use the domain name listed in the Certificate Application.

via VeriSign Symantec, Certificate Repository, June 2011 https://www.verisign.com/repository/rpa-ua/index.html