Mooshup: The yougest member of the OpenID family

WSO2 Mashup team recently upgraded their community site, Mooshup, with the Mashup Server 1.5.1.

With this, Mooshup enbles OpenID login - in addition to the Information Card based login, which it had already supported.

Randall says, the OpenID initiative, a 'waste of energy'.

Randall Stross in his recent article to The New York Times, highlights some of the very valid issues against the use of passwords.

"I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them."

Best practices on selecting better passwords always only provide guidelines for how to select a password which is 'hard to guess' - NOT unbreakable. With this point, I totally agree with Randall - Yes, true - passwords do not seem to be the 'right' solution for digital identity.

He further adds.

"As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code."

Yes, true - information cards provide a cryptographic solution to the authentication problem in a phishing resistant manner.

Even in this case - passwords are not totally taken out of the picture.

A given information card can be backed by a username/password, a self-issued information card or an X.509 token.

Also, in all three cases - if your machine, where you have installed all your Information cards, is protected by username/password - still we have not totally eliminated the risk of using passwords. Anybody who steals your machine username/password can easily use any of your information cards to authenticate in to any of the relying party web sites who accept your information cards.

Here comes the most interesting part of Randall's article.

"We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials."

Oops... I am sorry... I totally disagree.

First I disagree with him on the point about Information cards.

CardSpace has made a good progress in the past and it will definitely in the future. It's not just Microsoft that has taken the CardSpace initiative forward - but it has also attracted many open source vendors as well. For example, WSO2 with it's Identity Solution has support for CardSpace - both as an Identity Provider as well as providing relying party components.

Second - I totally disagree with him on his comments on OpenID.

"...however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative."

When such a comment is made - there needs to be enough facts to elaborate more on it. But, unfortunately there is nothing in it to justify.

Both OpenID and CardSpace are two technologies which support user-centric identity.

When you say - 'OpenID vs CardSpace' - it's simply an invalid statement. It should be 'OpenID and CardSpace'. Both the technologies work together smoothly. Please read this blog post by Kim Cameron.

"...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site."

This is totally misleading.

OpenID specifications never promote a single way of authenticating users to the OpenID Provider.

It can be username/password ,X.509 certificates or even Information cards.

I can take out many examples from the the web which support many of these authentication mechanisms for user authentication.

Randall, further adds.

"...Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised."

Once again - it seems Randall has misunderstood OpenID as a way of password-based login - sorry, sir - it is not.

Passport vs OpenID vs Facebook Connect

A nice post by Dick Hardt, read it here...

MySpace confirms OpenID support

MySpace announced yesterday to add support to OpenID by acting as an OpenID Provider.

This is the first ever leading social networking site to announce it's support towards OpenID.

Hope, Facebook will also follow...

Further details available here...

Deploying WSO2 Identity Solution over an existing MySQL user store

WSO2 Identity Solution can be used as an Information Card provider as well as an OpenID Provider.

This post explains how you can customize WSO2 Identity Solution to expose an existing user base residing on a MySQL database - and facilitate them with Information Cards and OpenID logins.

Let me further explain this scenario.

You have a set of users with a set of attributes defined for each.

Now the requirement is your company wants you to assign each of your users an OpenID and also run an OpenID Provider your self - and you need to do minimal changes to the existing system.

I'll explain everything you need to know here in a step-by-step manner.

Setting up the existing environment

- Download WampServer 2.0 from here and install it locally.

- Start the wampserver and run MySQL service.

- Add [WAMP_INSTALLED_LOCATION]\bin\mysql\mysql5.0.51b\bin to the PATH env variable.


:\>mysqladmin -u root password mysql

:\> mysql -u root -p

[type your password : mysql]

mysql> CREATE DATABASE COMPANY_DB;

mysql>USE COMPANY_DB;

mysql>CREATE TABLE `users` (`uid` varchar(60) NOT NULL,`name` varchar(60) NOT NULL,`pass` varchar(32) NOT NULL,`mail` varchar(64) ,`openid` varchar(60) NOT NULL, `firstName` varchar(60) NOT NULL,`lastName` varchar(60) NOT NULL,PRIMARY KEY (`uid`));

mysql>INSERT INTO users VALUES ('prabath','prabath','prabath','prabath@wso2.org','http://localhost:12080/user/prabath','prabath','siriwardena');

mysql>COMMIT;

Now we are done with setting up the existing environment.

You may have already noticed that for my convenience I created the 'users' table with an 'openid' column - which you may not have in your existing 'users' table. In that case you need to alter the table 'users', add the new column 'openid' and populate that column with values derived from the 'uid' column - which will create unique OpenIDs for all your users.

Building & deploying WSO2 Identity Solution from source

- Download the latest code from the SVN repo: https://svn.wso2.org/repos/wso2/trunk/solutions/identity

- Then, from the root directory (say [Identity] ) of the downloaded code.

[Make sure you have installed Maven2]

:\> mvn -Drelease clean install

-The above will create a zip file distribution at [Identity]\modules\distribution\target.

- Unzip the Zip file to a local folder.

- Download MySQL JDBC driver from here and copy the mysql-connector-java-5.1.6-bin.jar to [IS_INSTALLED_DIR]\lib

- You also need to download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 from here and copy the two jar files from the extracted jce directory (local_policy.jar and US_export_policy.jar) to $JAVA_HOME/jre/lib/security.

- Start WSO2 Identity Solution with [IS_INSTALLED_DIR]\bin\wso2is.bat

Configuring WSO2 Identity Solution to use MySQL user store

- Go to url : https://localhost:12443/admin and login with admin/admin [user/password] - then select 'User Stores'



- Click 'sampleRealm' link [Here we are using the JDBCRealm to connect to the MySQL database].



- Click 'Edit'



- Set the following properties appropriately and update.

UserCredentialColumn : pass
ConnectionPassword : mysql
ConnectionUserName : root
ColumnNames : mail,openid,firstName,lastName
DriverName : com.mysql.jdbc.Driver
UserNameColumn : uid
ConnectionURL : jdbc:mysql://localhost/COMPANY_DB
UserTable : users



- Click 'Set as Default' against 'sampleRealm'.



- Click on 'Define Claims' and select 'Given name','Surname' & 'Email address' [Dont uncheck any claims which are already selected]



- Click on 'Claim Mappings'.



- Click on 'Given name','Surname','Email address' and 'OpenID', and do the claim mapping appropriately.



- Once done the claim mapping it should look like the following.



- Try login to Identity Solution with your credentials available in MySQL database [ in our case prabath/prabath] - go to the url : https://localhost:12443



- To test your OpenID [http://localhost:12080/user/prabath], Signout first and from the Home page [https://localhost:12443], Click on OpenID and then type your OpenID.

You can find more documentation on WSO2 Identity Solution from here.

Mashup Server ready to ship with OpenID support

WSO2 Mashup Server latest release 1.5 is ready to ship on next Monday with OpenID support.

OpenID relying party support on Mashup Server is powered by WSO2 Identity Solution relying party components.

Further details on this new release available here.

OpenID with PAPE in plain English

This post discusses how PAPE works and demonstrates it's usage with WSO2 Identity Solution.

[You may also read this blog post by Nandana on "OpenID, Phishing & PAPE, Are we there yet? "]

Let me first explain what PAPE is.

PAPE stands for OpenID Provider Authentication Policy Extension - which is an extension to the OpenID Authentication.

An extension to OpenID Authentication is a protocol that "piggybacks" on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.

With PAPE, an OpenID Relying Party can add additional information into the OpenID Authentication request - such as;

1. preferred_auth_policies
2. max_auth_age

Let me explain what each one of them means.

With preferred_auth_policies, an RP can attach zero or more authentication policy URIs that the OP SHOULD conform to when authenticating the user. If multiple policies are requested, the OP SHOULD satisfy as many as it can.

Let me make this much clearer.

If RP wants it's users to be authenticated in a phishing resistant manner, then RP will attach the policy URI, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant as the preferred_auth_policies.

If RP wants it's users to be authenticated in both a phishing resistant manner and a multi-factor way , then RP will attach the policy URIs, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and http://schemas.openid.net/pape/policies/2007/06/multi-factor as preferred_auth_policies.

One thing I want to emphasize here...

Given the fact that RP requested OP to do the user authentication in such a manner - does not mean OP will follow the exact authentication policy request.

In other words, an RP could request OP to authenticate it's users in a phishing resistant manner - but in case OP does not support phishing resistant authentication, then it will simply authenticate the user with the available method. But... OP will also let the RP know the method it used to authenticate the user. So - it becomes a decision up to the RP to decide whether to let user in or not.

Let's see how this works in a practical scenario.

We have hosted the WSO2 Identity Solution at https://is.test.wso2.org and the PAPE demonstration is available at https://is.test.wso2.org/javarp/.

Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your Yahoo OpenID there.

Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.

In this case an OpenID RP sends a PAPE request to an OP which does not support PAPE [Yes, Yahoo still does not support PAPE].

This is what you get as the response.

Authentication Policies: none
NIST Auth Level: 0
Auth Age: -1

For the time being lets only focus on "Authentication Policies" - here Yahoo OP returns no policies. That is Yahoo has ignored the PAPE request by the RP. So, now RP can decide whether to let user in or not.

Let's try another example. This time we use an OpenID from WSO2 OpenID Provider. You can go there, register yourself and get an OpenID.

WSO2 OpenID Provider supports login with both the username/password and Information Card based logins.

First directly login to the OP and then register a self-issued Information Card with the OP. We'll be using this Information card later-on to login.

Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your WSO2 OpenID [http://is.test.wso2.org/user/test] there.

Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.

In this case an OpenID RP sends a PAPE request to an OP which supports PAPE.

So, once you are redidirected to OP for authentication, login with your registered Information card.

You'll get the following as the PAPE reponse.

Authentication Policies: http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
NIST Auth Level: 1
Auth Age: -1

This indicates you've being authenticated in a phishing-resistant manner.

In no means, PAPE does not limit you to the following three authentication policies.

1. http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
2. http://schemas.openid.net/pape/policies/2007/06/multi-factor
3. http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical

Additional policies can be specified elsewhere and used between OPs and RPs.

For example, myOpenID defines the policy URI, http://janrain.com/pape/callverifid.html for it's CallVerifID. In this post I blogged about how CallVerifID works.

Hope, by now it's very much clearer how PAPE works.

There are few things I skipped during the discussion.

Let's go back to them.

In PAPE request, RP also can add the parameter "max_auth_age" as well.

This is an optional parameter in the PAPE request, where the RP may or may not request.

Once max_auth_age is set in the PAPE request, if the End User has not actively authenticated to the OP within that number of seconds [max_auth_age] specified in a manner fitting the requested policies, the OP SHOULD authenticate the End User for this request.

Let's go back to the PAPE response. I skipped explaining two parameters, NIST Auth Level and Auth Age.

If the RP's request included the "max_auth_age" parameter then the OP MUST include "auth_time" [Auth Age] in its response. If "max_auth_age" was not requested, the OP MAY choose to include "auth_time" in its response or just send "-1" as the value.

The NIST Auth Level is the the Assurance Level as defined by the National Institute of Standards and Technology (NIST) corresponding to the authentication method and policies employed by the OP when authenticating the End User.

This value varies from 0 to 4 (inclusive).

The following table provides examples of common authentication technologies and their mapping to NIST Assurance Levels.

Let the rest discover your OpenID relying party

Let me first explain what OpenID Relying Party [RP] discovery is and what it is for.

This is a new feature introduced in OpenID Authentication 2.0.

With, RP discovery, you let software agents/OpenID Providers discover your site as an OpenID relying party.

OpenID providers use this feature to automatically verify that a return_to URL in an OpenID request is an OpenID relying party endpoint for the specified realm.

Have you ever seen this warning by Yahoo! - when you trying to use a Yahoo OpenID?

"Warning: This website does not meet Yahoo!'s requirements for website address. Do not share any personal information with this website unless you are certain that it is legitimate. "

This happens because, the relying party web site fails to meet OpenID RP discovery requirements.

Usually, as per the spec RP has to present an XRDS document in the following format, where the OpenID Provider can discover.

<Service xmlns="xri://$xrd*($v*2.0)">
    <Type>http://specs.openid.net/auth/2.0/return_to</Type>
    <URI>https://is.test.wso2.org/javarp/openidloggedin.jsp</URI>
</Service>

When it comes to Yahoo OpenID Provider, it tries to find this XRDS document at the return_to url [return_to url is included in the OpenID authentication request it self].

So, make sure you have RP discovery information available at your return_to url.

This is how you do it.

Say for example, if your return_to url is https://is.test.wso2.org/javarp/openidloggedin.jsp, when you set it in the OpenID authentication request, you need to set it as below, with an added parameter.

https://is.test.wso2.org/javarp/openidloggedin.jsp?login=true

Also, you need to set your realm as https://is.test.wso2.org/javarp/openidloggedin.jsp.

If you are using WSO2 OpenID Relying Party components, this is how you set your return_to url and the realm in the authentication request.

[This article explains how to add OpenID support to your RP web site with WSO2 OpenID RP components, please refer the section "Adding OpenID Support with Simple Registration"]

openIDAuthRequest.setRealm("https://is.test.wso2.org/javarp/openidloggedin.jsp");
openIDAuthRequest.setReturnUrl("https://is.test.wso2.org/javarp/openidloggedin.jsp?login=true");

Now, you can differenciate a 'login' request from a 'RP discovery' request.

Your openidloggedin.jsp page will have the logic to present the XRDS document for RP discovery, based on the request.

<%@page import="java.io.PrintWriter"%>

<%

String login= (String) request.getParameter("login");

if (login==null)
{
String xrd = null;
response.setContentType("application/xrds+xml");

xrd = "<xrds:XRDS xmlns:xrds=\"xri://$xrds\" xmlns:openid=\"http://openid.net/xmlns/1.0\" xmlns=\"xri://$xrd*($v*2.0)\">\n" +
   "<XRD>\n"+
   "<Service xmlns=\"xri://$xrd*($v*2.0)\">\n"+
   "<Type>http://specs.openid.net/auth/2.0/return_to</Type>\n"+
   "<URI>https://is.test.wso2.org/javarp/openidloggedin.jsp</URI>\n"+
   "</Service>\n"+
   "</XRD>\n"+
   "</xrds:XRDS>";

PrintWriter writer = response.getWriter();
writer.write(xrd);
}
else {
//User logs in... add your logic appropriately
}

%>

To see a demonstration of how this works, go to https://is.test.wso2.org/javarp/, and type your Yahoo OpenID at "OpenID Simple Registration Demo".

WSO2 Beefs Up SOA Identity Solution

Read the complete article on ebizQ...

Deploying your OpenID relying party behind a proxy

This post dicusses how you can deploy your OpenID relying party behind an Apache front-end, which acts as a reverse proxy.

First, lets configure Apache to act as a reverse proxy. I assume your Apache server is running at identity-rp:12081 and your web application is running on Tomcat at http://localhost:12080/javarp. If you have different settings, please do the modifications appropriately.

Do the following changes in the httpd.conf.

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

ProxyRequests Off
ProxyPreserveHost On

ProxyPass /javarp http://localhost:12080/javarp

<Location /javarp/>
     ProxyPassReverse /
     SetOutputFilter proxy-html
     RequestHeader unset Accept-Encoding
</Location>


Now let's download the latest code from the SVN repo: https://svn.wso2.org/repos/wso2/trunk/solutions/identity

Then, from the root directory (say [Identity] ) of the downloaded code.

[Make sure you have installed Maven2]

:\> mvn -Drelease clean install

You need the following two jars from the build and copy them to your classpath.

1.[Identity]\modules\base\target\wso2is-base-SNAPSHOT.jar
2.[Identity]\modules\token-verifier-core\target\wso2is-token-verifier-core-SNAPSHOT.jar

This article explains how you can develop an OpenID Relying Party web site with WSO2 OpenID RP components. Please refer the section "Adding OpenID Support with Simple Registration".

You also need to do the following changes in addition to what is mentioned in the above document.

Set the return_to url;

openIDAuthRequest.setReturnUrl("http://localhost:12080/javarp/openidcallback.jsp");

Add the following to the web.xml of your web application.

<filter>
  <filter-name>OpenIDTokenValidator</filter-name>
  <filter-class>org.wso2.solutions.identity.relyingparty.servletfilter.OpenIDRelyingPartyFilter</filter-class>
    <init-param>
      <param-name>MappingHost</param-name>
      <param-value>localhost</param-value>
    </init-param>
    <init-param>
      <param-name>MappingPort</param-name>
      <param-value>12080</param-value>
    </init-param>
    <init-param>
      <param-name>MappedHost</param-name>
      <param-value>identity-rp</param-value>
    </init-param>
    <init-param>
      <param-name>MappedPort</param-name>
      <param-value>12081</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>OpenIDTokenValidator</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>


All done and now you are set to run your web application.

Start both the Apache and your Tomcat servers and hit the url http://identity-rp:12081/javarp to access your web application.

Demand OpenID...!!!

Demand OpenID support from websites you sign in to every day, using a simple bookmarklet.

More info available here...

Microsoft HealthVault about to add OpenID support

HealthVault is a hub of a network of Web sites, personal health devices and other services that you can use to help manage your health. HealthVault lets you store the information in one central place on the Web.

Sean Nolan, chief architect of Microsoft’s HealthVault talks here about adding OpenID support to HealthVault.

Initially it's going to accept OpenIDs only from Verisign and TrustBearer.

Currently HealthVault uses Windows Live ID for login.

Understanding OpenID

| View | Upload your own

OpenID RP count goes beyond 13,000

myOpenID announced here that the unique RP web sites seen by myOpenID, count to 13196 at the end of April 2008.

They have striped out what appears to be purely developer testing and anything with localhost, .local, ports other than 80 & 443 were not considered.

TAG recommends against XRI

"We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications"

- Tim Berners-Lee and Stuart Williams, co-chairs, W3C Technical Architecture Group

More details available here...

OpenID 2 added the support for XRIs as Identifiers. XRIs may be used as Identifiers for both end users and OPs, and provide automatic mapping from one or more reassignable i-names to a synonymous persistent Canonical ID that will never be reassigned

CallVerifID by myOpenID.com

This is another cool feature by myOpenID.

With this myOpenID enables multi-factor authentication.

You simply need to add a phone number [still this works only in US] to enable CallVerifID and you'll recieve a call immediately to verify the number. Once done - after each authentication you'll recieve a call to the given phone number and ask for your confirmation. You can confirm authentiation by pressing '#' on your phone.

You can further expolre this by visiting the WSO2 relying party hosted at https://is.test.wso2.org/javarp.

There you can find the demo 'OpenID PAPE Demo' - simply type your OpenID there and check "http://schemas.openid.net/pape/policies/2007/06/multi-factor" - you'll be redirected to myOpenID.com - where you need to type your password first and then you'll recieve a call to complete the authentication.

Once you are redirected back to the relying party web site - see the out put on the screen.

Authentication Policies: http://janrain.com/pape/callverifid.html http://schemas.openid.net/pape/policies/2007/06/multi-factor

Webinar on OpenID

OpenID is a much favored key feature in decentralizing single sign-on. This webinar will focus on OpenID Authentication 2.0 and other related OpenID extensions with the security issues associated with them and will further discuss the different approaches being taken to integrate Information Cards with OpenID.

Now you can register for this webinar and more information available here.

Understanding OpenID Association

Before getting into more details of how OpenID Association works, better we start with understanding how Diffie-Hellman key-exchange works.

Let's discuss this under the context of OpenID.

We have two parties interested in sharing a secret key through a non-secured media.

Let one of these be an OpenID Relying Party [RP] and the other be the OpenID Provider [OP].

So, RP and OP want to share a secret key between each other through a non-secured media.

Under Diffie-Hellman key-exchange, they need to do the following to establish a secret key.























Step 1: Both RP & OP agree on two values "g" and "p". The values of "g" and "p" can be known to any body - even other than the RP and the OP. Under the context of OpenID, these values are defined in the OpenID Authentication Specification. Basically, "p" is a large prime number and "g" is a small number.

Step 2: RP selects a secret number, say "x" - which is typically a large number and compute another number, "X" - with the values of "g" and "p", where X = g^x mod p. Now RP can share "X" with OP [or anybody else] - which is the public key of RP - but it will still maintain "x" as a secret.

Step 3: OP will also select a secret number, say "y" - which is typically a large number and compute another number, "Y" - with the values of "g" and "p", where Y = g^y mod p. Now OP can share "Y" with RP [or anybody else] - which is the public key of OP - but it will still maintain "y" as a secret.

Step 4: Since the public key of OP - "Y" is known to anyone - RP can derive the Diffie-Hellman secret key [Kx] between OP and RP.

Kx = Y^x mod p

Although, "Y" is known publicly - "x" is kept as a secret at the RP - so nobody other than RP, can compute the value of Kx.

Step 5: Since the public key of RP - "X" is known to anyone - OP can derive the Diffie-Hellman secret key [Ky] between OP and RP.

Ky = X^y mod p

Although, "X" is known publicly - "y" is kept as a secret at the OP - so nobody other than OP, can compute the value of Ky.

Step 6: All set - we are done. Under the Diffie-Hellman key-exchange, Kx=Ky - so OP and RP shared a secret key between each other.

Okay - now we are done understanding Diffie-Hellman key-exchange. Let's start with understanding how OpenID Association works.

OpenID Authentication supports both a "smart mode" and "dumb mode" to accommodate Consumers of differing capabilities. A smart Consumer does a little more work at the beginning to save itself work later, but requires local caching of state information. A dumb Consumer is completely stateless, but requires extra an HTTP request.

Under "smart mode", it's recommended that a RP first submits an associate request (associate) to the End User's OP and requests a shared secret if the RP does not already have one cached.

So, the request for "Association" will take place after the "Discovery" - that is after the OP server url being discovered from a given OpenID.

The "Association" request is initiated by the RP using direct communication message called "associate" with an HTTP POST.

Let's discuss some of the important parameters included in an "associate" request.

1. openid.mode : This will have the value "associate" - indicates OP that this is an "associate" request.

2. openid.assoc_type : This defines the algorithm to be used to sign subsequent messages. OpenID 1.1 supported only HMAC-SHA1. HMAC-SHA256 was added in OpenID 2.0. In other words once an "association" being established between OP and RP - the same will be used for subsequent OpenID authentication requests between these OP and RP.

3. openid.session_type : This defines the method used to encrypt the association's MAC key in transit. MAC key is the shared key established between the OP and RP. Don't confuse this with the Diffie-Hellman shared secret. We basically use Diffie-Hellman shared secret to protect the MAC key [shared key] - will explain this more further later in this post.

openid.session_type can have any of the following values.

a. no-encryption
b. DH-SHA1
c. DH-SHA256 [Added in 2.0]

In a "no-encryption" association session, the OP sends the association MAC key in plain-text to the Relying Party. This makes it possible for an eavesdropper to intercept the key and forge messages to this Relying Party when not using transport layer encryption. Therefore, "no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption.

The "DH-SHA1" and "DH-SHA256" association session types use Diffie-Hellman Key Exchange to securely transmit the shared secret - that is MAC key. In other words if you use "DH-SHA1" or "DH-SHA256" as the association session type - first OP and RP will derive a Diffie-Hellman shared secret, as explained in the beginning of this post, and will use that shared secret to encrypt the MAC key.

The following parameters are common to requests whose requested association session type is "DH-SHA1" or "DH-SHA256".

4. openid.dh_modulus : This is the value of "p" used in Diffie-Hellman key-exchange, where the default value defined in the spec.

5. openid.dh_gen : This is the value of "g" used in Diffie-Hellman key-exchange, where the default value defined in the spec.

6. openid.dh_consumer_public : This is the public key of RP for Diffie-Hellman key-exchange [X].

Once the OP receives the "associate" request - it will generate a MAC key and encrypt the MAC key [if "DH-SHA1" or "DH-SHA256" being used] with the Diffie-Hellman shared secret. OP will also share it's Diffie-Hellman public key with the RP through the response - so RP can derive the Diffie-Hellman shared secret from it and decrypt the MAC key.

Following are the important parameters is in the "associate" response.

1. assoc_handle : The association handle is used as a key to refer to this association in subsequent messages. assoc_handle will be used as key at both the OP and RP ends to cache the values associated with "associate" message.

2. expires_in : The lifetime, in seconds, of this association. The Relying Party MUST NOT use the association after this time has passed.

3. mac_key : The MAC key (shared secret) for this association, when "no-encryption" is used for session_type in the "associate" request.

4. dh_server_public : OP's Diffie-Hellman public key

5. enc_mac_key : The MAC key (shared secret), encrypted with the secret Diffie-Hellman value.

Once an "association" is established between the OP and the RP - the same "association" will be used for subsequent authentication requests. In other words, when a RP requests authentication for a given OpenID - it will include the already established assoc_handle in the authentication request.

Since the assoc_handle is passed to the OP - it will retrieve the cached MAC key using assoc_handle as a key, and will use that to "sign" the attributes before sending the response.

Improve your Google PageRank with OpenID

Under Google PageRank, the importance of a page is judged by the number of pages linking to it as well as their importance.

Higher the citations to your web site from the rest - higher the PageRank.

Turn your blog(web site) to your OpenID - my previous post explains how to do that - and start commenting on other sites with your OpenID - which automatically links back to your web site.

BBC joins OpenID Foundation

Read the announcement here...

A company/organization joining OpenID foundation will have the following benefits and the annual membership fee varies from $100 to $10000.

-Use the OpenID Foundation Member logo on your company website, blog, and other marketing materials
-Display your corporate logo/name on the OpenID Foundation website and promotional materials
-Propose, lead, and participate in OpenID technical and marketing work groups
-Vote on ratification of OpenID specifications and recommendations
-Be eligible for inclusion in OpenID Foundation press releases and industry events
-Opportunity to meet, exchange views, collaborate with peer organizations in innovative, open source efforts