In the previous post, I have shown that the Authentication Service can be made protable and that this is very important to prevent identity loss. One can prepare any number of XRD files and locate it anywhere he wants to make sure that his identity is not going to be lost on the net, as long as he can prove that XRD file is authentic.

How do we prove it?

One way to do it is to obtain the signagure from the Identity Attestation Service (IAS). The job of the IAS is to verify that the user is the rightful owner of the identifier and sign the XRD document presented by him.
The resulting XRD may or maynot have the user’s core identifier, but MUST include the permanent identifier as <Subject> . Of course, the user can self attest but that means he has to have his own cert/key-pair and in general, his ability of being uncorrelatable at the RPs are lost because he has to expose his public key.

So, the user now has a signed XRD. He can place it anywhere on the net. The trust is coming form the IAS, so if either the RP or Authentication Service do not trust the IAS, the flow breaks. In that case, the user should obtain a signed XRD from another IAS.

OpenID 2.0 has a problem such that permanent unique identifier generation is delayed until it gets to the authentication service. As a result, a user has no ability to change the authentication service. This implies that user cannot change the authentication service according to the authentictaion method requirement, he cannot enjoy the failover of the authentication service. Moreover, if the OpenID Authentication Service cease to exist, he will loose his online identity - He will become unable to login to many sites. IMHO, this is the worst weakness of OPenID 2.0. This is not theoretical. With several OP going away recently, this is the reality.

This needs to be addressed.

The way to address it is to leverage on the Discovery service, like XRI. The Discovery Service should return the permanent identifier, and authentication service should just use it.

The flow is like this.

Case 1: User Specified Identifier

In this use case, the user does not care too much to be anonymous to the RP, so he enters his identifier to the RP. This is the basic case.

1. The user access the RP and enters his identifier (Display Name/Alias).
2. The RP finds out the discovery service for the identifer through appropriate bindings. (The simplest case is that the user supplied identifier is the location of his XRD.)
3. The RP obtains the XRD document associated with the identifier.
4. In the XRD document, there is a permanent and unique identifier (Canonical ID/Subject) as <Subject> and bunch of OpenID Authentication Services (AS).
5. The RP choses the highest priority AS and creates AuthN request with Alias+Subject (AuthnReq).
6. The RP sends AuthnReq to the AS. [1]
7. AS authenticate the user by making him enter password etc.
8. AS creates the AuthnResponse and sends it back to the RP.
9. RP verifies the AuthnResponse

Note that by the time it reached the authentication stage, the identifier is completely specified so it makes no difference when on switched the authentication service.

Case 2: OP Identifier

If the user cares to be anonymous, he needs to use OP identifer. This means there is an extra steps before.

1. The user accesses the RP and specifies his Discovery Service (e.g., clicking on the button).
2. The RP redirects user to the Discovery Service (DS).
3. The User enters his identifier
4. The DS generates an XRD with PPID (Pairwise Pseudonym Identifier) and returns it to the RP via browser redirect
5. Upon receipt of PPID, RP starts the process described in Case 1 using this PPID as the user’s identifier.

Now that Contract Exchange WG ML has been set up at openid.net, we should be able to start discussing it.

=hdknr is busily preparing the initial document for the current thought now (which is going to be submit around Wednesday), but I will start introducing concept here little by little. (I thought of using wiki.openid.net but I did not know whether I can control the edits so that we do not get exposed to IPR pollution, so I am doing it here.)

The main concept of the Contract Exchange is to exchange the public key signed contract among “parties”. Basic model calls for two parties, with two additional signatories. Under current situation, Signatories are typically servers.

There will be a contract proposal (offer) on the table to start with. It is signed by the Offerer. The signature achieves two things:

1) Non-repudiation: The offerer really made the offer.
2) Integrity: The accepting party cannot change the offer.

Once the accepting party reads the offer and agrees to it, the contract is established, and to signify it, the accepting party will counter-sign the document.

That’s all what it does.
It could subsequently be used as a token to obtain further data or service, i.e., just like an Access Token of OAuth.

The protocol that we have been talking at various venues (such as IIW) is actually very simple. It is almost a simplified version of OAuth with a tweak.

So, now you understand: There are two important parts in CX.

1) Contract Format
2) Protocol to exchange signed contract.

Of the two, 2) is actually easier, as I mentioned above.

In the following posts, I will talk about each.

For those of you who do not know, Chidorigafuchi in Tokyo is one of the best places in the world for Cherry Blossom.

For more photos, see my flicker photo set.

ritou’s blog post prompted me to think a little about this issue.

IMHO, there are two reasons.

(1) Cannot trust the RP.
(2) Legal problem.

In the U.S., (1) would be the main problem, I suppose. Thus, white listing through OAuth consumer key or realm based etc. white listing for OpenID seems to be the way.

In other OECD jurisdictions, (2) would be an even larger problem. If it is a decent business, it cannot pass the PII to a third party without permission. Now, to prove that one has this permission is rather problematic, because when obtaining a permission, it has to state the clear purpose and scope of use, which may differ from transaction to transaction. A wholesale pre-agreement does not work here.

That’s why we need some kind of dynamic contract framework such as CX or ProtectServe, which essentially has a Relationship Manager that controls this “contracting” dynamically.

General pattern of protocol flow in OAuth and CX Artifact Binding is almost identical.

Just to assist the OAuth people to understand CX easily, here are the glossary of the terms.

Here after, I will write this article in OAuth terminology and express CX terminology like cx:Offer.

Message Flow Comparison

From the message flow point of view, it is completely identical.
The difference is that CX’s version has much richer structure.

For example, cx:Offer (Request Token Request) has “Consumer” identity, its public key, term and conditions, “Consumer” pub-key based signature etc. in it, and cx:Contract (Access Token) has User’s identity, Service Providers Public Key, Service Provider Signature, etc.

Now, let us dive into protocol difference.

(Source: OAuth Core Final 1.0. Click to Magnify)

There are some differences in the details.

In B above, OAuth returns Unauthorized Request Token and Request Token Secret which is used as a part of signature key (consumer secret + token secret) . Unauthorized Request Token is bound to the Local ID of the “Original” User. In CX, it is either not bound to anybody at this stage, or if it is, the Users global identifier (e.g., OpenID) is explicitly written in the Request Token Request (cx:Offer).

In C, to obtain Authorized Request Token (cx:ContractID), the Token is sent (or input) to the Service Provider.

At this point the (hopefully the original) User identifies himself (by something like username and password.) Note that there is no guarantee that the User here is the same User that started off the Request Token Request. This is one source of OAuth Fixation Vulnerability. If the User is the victim of this attack, his local identity at the Service Provider is effectively linked to the attacker’s (Original User’s) identity at the Consumer.

In CX, if the user was not identified at the Consumer, then his global identifier is verified at the Service Provider and written into the Access Token (cx:Contract). If the user was identified at the Consumer, then its global identity is already written in the Request Token Request (cx:Offer), and thus in the Access Token (cx:Contract). Thus, OAuth Fixation vulnerability does not exist here. It is simply not possible to link a user at the Consumer to another user at the Service Provider.

Once the user was identified, and an appropriate authorization/permissioning happens, Authorized Request Token (cx:ContractID) is generated. At this point, the Authorized Request Token is bound to the User at the Service Provider in OAuth. In CX, Access Token (cx:Contract) is generated here as well, and User’s Identifier is written into the Access Token (cx:Contract). Of course, if the identifier in the offer (if not identifier_select) and the identifier of the User at the Service Provider does not match, it fails.

In step D, this Authorized Request Token (cx:ContractID) is returned to the Consumer via browser redirect.

Then, in step E, Consumer requests Access Token (cx:Contract) using Authorized Request Token (cx:ContractID) and Consumer Secret + Request Token Secret as the Key of the signature. In case of CX, we just use Consumer’s secret key to sign the request.

In OAuth, at this point Access Token (cx:Contract) is generated. Note that in CX, it was generated before step D.

In F, Access Token (cx:Contract) and Access Token Secret (cx: no such thing) is returned, which is subsequently used to access resources. In CX, this is optionally encrypted by the Consumer’s Public Key obtained through Request Token Request (cx:Offer), so that nobody but only the Consumer can read it.

Summary

So, to summarize:

1. OAuth and CX is almost identical in the protocol flow.
2. OAuth requires manual step to establish the Consumer’s identifier called Consumer Key, while CX leverages on metadata including its identifier in XRD.
3. OAuth does not require an identity framework such as OpenID while CX does.
4. OAuth uses Token Secrets. In CX, there is no need of them.
5. CX leverages on public key cryptography for security while OAuth depends on shared secret. In another words, in CX, there is no shared secret.
6. Authorized Request Token (cx:ContractID) and Access Token (cx:Contract) is generated at different point in the sequence in OAuth, while it is generated simultaneously in CX.
7. OAuth implicitly assumes that the User at the Consumer and the Service is the same guy and binds a local user at the Consumer to another local user at the Service Provider by Request Token, while CX does not and leverages on the User’s global Identifier to distinguish them.
8. OAuth implicitly assumes that the User in the different point in the sequence is the same guy, while CX does not and leverages on the User’s global Identifier to distinguish them.
9. In CX, the authorization fails if the identifier in the cx:Offer/cx:Contract does not match with the User’s Identifier
10. CX is not vulnerable to the OAuth Fixation Attack, though on the surface, the protocol flow seems almost identical.

Comments on OAuth Vulnerability Fix Proposals

It seems there are two proposals on the table [2].

• Signed Callback URLs
• Signed Approval URLs

IMHO, they are not dealing with the core of the problem. The core of the problem is the identification of the users at each site and the conflation of the potentially different identity over time and location. The above may work for this vulnerability, but it is just patching a hole and not coping with the real problem. I am very sleepy (I have slept only two hours each for last couple of days…) so I might be wrong, but sending the Local ID of the requesting party (the Original User) with the Request Token Request (cx:Offer) and Service Provider prominently showing this to the User might be a better idea.

[Related Articles]

[1] http://oauth.net/core/1.0/
[2] http://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory
[3] http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html
[4] http://www.readwriteweb.com/archives/how_the_oauth_security_battle_was_won_open_web_sty.php
[5] http://groups.google.com/group/oauth/browse_thread/thread/e9b205c8c21f8f3c
[6] http://apiwiki.twitter.com/Sign-in-with-Twitter

I had a talk with ProtectServe folks yesterday and it inspired something about what Contract has to have.

Until the meeting, the basic items that I had in mind were following:

- Subjects
- Signers (If Subject!=Signer, Singer is a proxy and
asserting that he has the agreement with Subject
implicitly.)
- Human Readable Term Text
- Machine Readable Term
- Date
- Period of the Service
- Consideration for the Service (usually in dollar amount.)
- Liability (usually specifying the limit in dollar amount.)
- Corrective Measures
- Termination
- Confidentiality (May persist longer than the duration of the service.)
- Arbitration
- Jurisdiction

During the discussion, an issue with signing software/hardware came up. From the process point of view, it would be importat to know what was used to sign. Thus, probably, the identifier including versions of the software/hardware combination, or more simply put “System” needs to be recoreded somewhere.

Yes! Finally! Kantara Initiative is LIVE.

Kantara Initiative is a Bridging and harmonizing the identity community with actions that will help ensure secure, identity-based, on-line interactions while preventing misuse of personal information so that networks will become privacy protecting and more natively trustworthy environments. I have been working diligently on this project and I am so happy to see this date.

FYI, Kantara (kan-TAR-a): Kiswahili for “bridge”; Arabic roots in “harmony”, and
Initiative (i-NISH-ee-uh-tiv): an introductory act or step; leading action. When we were discussing the name back in February, the name just clicked inside me. (I grew up in Kenya, where Kiswahili [Swahili Language] is one of the primary language). Bridging and harmonizing the identity community - Is it not appropriate in this seemingly fragmented islands of Identity. Also, the fact that President Obama who is inaugurated this year has roots in Kenya, and the Federal CIO, Vivek Kundra, is from Tanzania and speaks Kiswahili added “timeliness”, too.

Yes, I know that some people in OpenID community/foundation are uncomfortable with the idea. (I do not know why, and I never got a good answer.) However, I strongly believe that we should not live in isolation. Creating Bridges to different islands.

One of the first output of this “Bridging” initiative is the OpenID/SAML Interop of the Concordia Working Group. It is done by NTT/NRI (my company)/Oracle that translates SAML AuthnContext Assertion into OpenID PAPE Assertion and vice versa. At the demo, you can see that one can login to an OpenID site using SAML IdP, login to a SAML site using OpenID Provider, etc.

Later today, I will be a part of Identity Assurance Panel at 3:30pm, so I might touch on it as well.

So, CHEERS to KANTARA INITIATIVE.

Together, we can change the world, cannot we?

I had a two hours talk with Andrew Nash Friday Afternoon around the security of assertion based technologies. It was a very productive meeting and reminded me of several things.

One of the main one is the separation of the responsibility and the liability properties.

From the business perspective, the security decision is always made on the cost benefit analysis basis. Thus, it is important to know what would be the liability of given transaction. i.e., it is important to know the financial and other obligation associated with each transaction. Usually, these are written in a normal contract in two separate section. The main deal and the liability associated with it for a rainy day, i.e., what each party has to pay if they could not fulfill their obligation.

CX has the following items in its standard message:

1. Identifiers of the Parties.
2. The main deal
3. Remedy and Liability
4. Period, Renewal, and Termination
5. Confidentiality
6. Jurisdiction
7. Signatures of the Parties

However, I have not specified that Liability section to have an explicit dollar amount in a structured way. (Well, it used to… but removed after Specs Coucil pointed out that he did not like it.) The discussion with Andrew reminded me of the importance of it, that cost benefit analysis portion of security decisions is so important that it would probably be beneficial to actually specify it in the core message. Needs to explore more.

When OpenID Japan formally started in October 2008, the number of the companies that joined it was 32.

Thereafter, companies continued to join in and as of Apr. 3, it is 48.

The companies that joined after our announcement in October 2008 are as follows:

* (A Magazine who wants to remain anonymous in public)
* 3Di
* Japan Certificate Service Inc.
* Kawaijuku
* Emardio
* Hitachi
* Indigo
* Japan Hewlett Packard
* NTT Data
* NTT Docomo
* NTT Communications
* Mitsubishi Tokyo UFJ Bank
* Digital Garage E-Context Company
* Secom Trust
* Cuon
* Nippon Life Insurance

These additions are somewhat significant. Now, we have the top bank and the top insurance company as our member. Three main mobile carriers are here as well. We are having additional certificate authorities, etc. It now has a very good coverage of industries so that their views can be represented.

OpenID Foundation Japan hosted the OpenID TechNight #4 at GINZA Apple Store on the 10th of February. I went there to attend it straight from Narita Airport.

Almost 120 peopel, which is 1.5 times the capacity of the hall came to attend it.
So, many people were standing, sitting on the isle, etc.

It simply shows the popularity and high interest rate against OpenID in Japan.

We need to capitalize it now because consumer interest will not last.

The lecture was given by tkudo and =zigorou.

After the event, some of us including the both lecturer flocked for a “drink” session, and much talk was done over the mobile profile of OpenID. =zigorou working for one of the largest mobile content provider, and there was another guy from one of the largest Japanese mobile carrier in it. I have recently started a thread on it at specs@openid.net, but I need to push it further. The problem is… I do not have time. Oh well… Is there someone who want to help?!

On Feb. 6, 2009, we had a meeting for OpenID Denmark.

The programme was as follows:

PROGRAM

13.00-13.15 Welcome and Introduction
13.15-13.45 Basics about OpenID and alternative SingleSignOn solutions (Martin Strandbygaard)
13.45-14.15 OpenID Market Development and Use Cases in Japan (Nat Sakimura)

14.15-14.30 Break

14.30-15.00 Status, Opportunities and Roadmap for OpenID (Nat Sakimura)
15.00-15.30 DK User Study: How do non-technical users perceive SingleSignOn (Henrik Biering)
15.30-16.00 Discussion: What is needed to promote the use of OpenID in Denmark?

It had an attendance from wide range of industry including a credit card processors to the national broadcasting corporation.

OpenID in Denmark is just starting, but when combined with its National ID infrastructure, which is going to be in a new version later this year, it has a potential to leap frog most of us. It is worth watching how it is going to evolve.

As of Jan. 1, 2009, apparently, Republic of Lithuania went OpenID. All the Personal ID Card that the Republic of Lithuania issues has OpenID in addition to X.509 in it. Lithuanian government is also going to provide a state run OpenID provider, which is under testing right now.

Congratulations Lithuania!

It’s a kind of pity that I did not know it couple of weeks ago because otherwise I could also have planned to visit Lithuania in this Europe tour.

The original article is in http://openid.net/pipermail/eu/2009-February/000280.html

The election result is now published.
It is at OpenID Board Election Results

Snorri Giorgetti, me, Chris Messina, David Recordon received two year terms and Eric Sachs, Scott Kveton, and Brian Kissel  received one year terms.

I would like to thank all of you for your support to elect me to the two years term.

For those of you who may not be famillier with those people, Snorri has been the main engine for the OpenID in Europe. He established OpenID Europe and has helped over 30 country level chapters to get establisehd in Europe. So, he has been an European counterpart to me (I being co-founding OpenID Japan.)

Chris is running Citizen Agency, and works on DiSo project facilitating the development of “OpenStack” for the social web. Together with David, he is also involved in OpenWeb foundation.

David has been a spokes person for the OpenID community at large, so you probably know.

Eric is heavily involved in the usability side of OpenID. Google’s study of it together with Yahoo! study has been regarded as one of the main input in this field.

Scott is a co-founder and the current chairman of OIDF. He brings with him his 12 years of experience building technology, developing business
strategy and leading engineering teams with companies like Amazon.com,
Rulespace, JanRain and now Vidoop to this community.

Brian has been a real work horse behind the scene. He has been Chairman of the Marketing Committee, co-founded the Customer Research
Committee among other things. We have seen significant increase in the work around OpenID Foundation recently, and that is partly because of his devotion.

I believe OpenID is entering a new phase, and am really excited by the new board. It is international, balanced, and committed. Together with the membership and the community, I am hoping to further advance the UCI.

On Dec. 22, Tokyo IT Newspaper published this year’s buzz word ranking. (http://itnp.net/category_betsu/24/2167/)

The ranking is done in Sumo Ranking style and They are Ranked as “Yokozuna (Grand Champion)”, “Ozeki (Champion, 2nd highest rank)”, “Sekiwake (Junior Champion, 3rd highest rank)” etc.

This year, Yokozuna was iPhone, which was no surprise since it was the first year in Japan. Ozeki was Google Street View, which is no surprise either.

What surprised me though was the 3rd highest rank, Sekiwake, which turned out to be OpenID. It ranked higher than NetBooks (eePCs etc.) or Google Chrome, etc.

Anyhow, it is good to hear something that is assuring our activity.

Here is the complete ranking (Sorry it is in Japanese…)

OpenID Foundation board election is going on till Dec. 24.

I have posted details and my candidacy statement here.

Please have a look.

By the way, here is my picture. This is from my TV appearance.

Since Oct. 30, OpenID Foundation Japan have added 9 corporate members. Many of them are very large corporations. (Since some of them do not want to be identified in public, and I do not have a list who is not, so I am not quoting their names here.) Now, it has 41 corporate members.

The members list is not updated yet, but I expect that it will be pretty soon.

Right after the BizDay #1, Nat rushed to this meeting to give his presentation this council.
This council is supposed to create a national guideline for e-Gov and possibly to the private sector for the usability and identity assurance. Prof. Sudo, an advisor to OIDF-J, is the chairman of this council. (Mr. Mitsushio, a member of OIDF-J, and the leader of the security working group of CIO aide of ministries, is another member of the council.)

For details, see http://www.kantei.go.jp/jp/singi/it2/guide/index.html (Sorry, it is in Japanese.)

The Agenda was as follows:

1. Opening Remarks
2. Status of E-Sigs usage
3. On the “Inference articles” of the e-sig and authentication law.
4. Technical Trends in the technologies that impacts user interface
 4.1 SmartCards and NFC phones
 4.2 Web SSO

I could only attend 4.2 (i.e., my speech) because of BizDay #1 obligation, so I cannot report on anything but my speech and discussion followed it. My presentation was on OpenID and SAML including PAPE and CX proposal, and gave several case studies as well. It was very well accepted. In the following discussion, the importance of the NIST SP800-63 style assurance framework and guidelines that can be used across government and private sectors were noted.

IMHO, this kind of activity is very important for OpenID adoption. There are many companies hesitant to become an RP because the assurance level and legal implication of being a RP is not clear. This kind of council will eventually come up with a national guideline and possibly a new law that covers these and thus make it much easier for something new like OpenID to be adopted.

On Dec. 12, OpenID Foundation Japan had a members only seminar titled “OpenID BizDay#1″, hosted by Yahoo! Japan.
BizDay is something OIDF-J is providing to the members as the benefit of being a paying member.
It is intended to be a forum for the members to share their business (non-technical) experience.

Dec. 12 was the first such occasion, and over 60 people across the industries attended it.

The agenda was as follows:

0. Opening Welcome Message: Koji Yagi, President, OpenID Foundation Japan
1. Keynote: “Next Generation e-government services and security - loosely coupled databases and Government-Industry collaboration.”
     Prof. Osamu Sudo, The University of Tokyo
2. “Yahoo! JAPAN and OpenID”, Tetsuya Nishimaiki, CTO, Yahoo! Japan.
3. “Developments in the U.S.”, Tatsuki Sakushima, NRI-A
4. “Interoperability considerations on ID management: A Concordia Project”, Hiroki Ito, NTT
5. Status report on the progress of OpenID Japan’s activity. Nat Sakimura, NRI
6. OIDF-J Activity Reports, Noboru Uchiyama, OpenID Japan/NRI
7. Member announcements and forthcoming OpenID Japan activities.
 - mixi OpenID Contest, Hiroyuki Oyama, mixi
 - OpenID BizDay #2, Noboru Uchiyama, OpenID Japan/NRI

To start the BizDay #1, Mr. Yagi gave a welcome message to the members for joining this forum.
He also announced that now OIDF-J has 3 additional members: Hitachi, HP Japan, Indigo, that now it has 40 corporate members.

Prof. Osamu Sudo is a renowned government advisor and is an advisor to the OpenID Foundation Japan.
He gave us the current e-gov situation and his insight on how OpenID etc. can help the situation.

Mr. Nishimaki gave an overview on the rationale for Yahoo! Japan to invest and support OpenID, and shared the roadmap with OIDF-J members. Also, he shared business ideas that Yahoo! Japan is considering right now.
It was also good to hear Yahoo! Japan’s basic privacy policy: “The customer owns the information he registered to Yahoo! Japan.”

Tatsuki gave us an update on the U.S. OpenID related development, such as the Board Election, New Working Groups being formed, XRD 1.0 at OASIS Open, etc. Then, he finished off his speach with the mention of OpenID PAPE - SAML Authn Context interoperability project which is supposed to be demoed at RSA 2009. This acted as a good introduction to HIroki’s announcement and introduction of the OpenID-SAML Interop Concordia project.

Nat gave a brief status report on the SIG formation etc. There has been bunch of SIG proposals and the option of starting them simultaneously were considered, but the direction now is to start one to debug the process, and then start others.

Then, Mr. Uchiyama reported on the activities of the past two weeks including Web 2008 Conference that OIDF-J sponsored.

The last portion was member announcement. There were two announcement.

The first one was the announcement of mixi OpenID Competition for students. Awards are going to be given to the teams with implementation that leverage on the social graph represented by mixi OpenID. Juries are composed of two people from mixi, one from OIDF-J, and two others.

The second announcement was the next OpenID BizDay hosted by Japan Airlines. It will be on January 16.
It will feature Japan Airlines’ OpenID strategies as keynote.

Nikkei ITPro Article: http://itpro.nikkeibp.co.jp/article/NEWS/20081212/321354/

On Dec. 10, IdCon #4 was held, hosted by NRI.

IdCon is a gathering of identity engineers and architects started earlier this year by tkudo and =zigorou.
It is a grass-root activity which does not require a membership fee.
It makes a good companion with OIDF-J, which is a for fee membership organization.

IdCon #4 was a fifth such event this year. (We started off from IdCon #0, by the way.)
 
IdCon #4 featured following sessions:

- Possibility of Mobile OpenID, =zigorou, Cybozu Labs.
- Liberty People Service, =hiroki, NTT Information Sharing Lab.
- Recent Developments around OpenID, =nat, NRI
- Drinking Party :pint:

=zigorou gave detailed analysis of the limitation of the current phones available in Japan and the impact of that to OpenID.

=hiroki gave an overview of Liberty People Service.

=nat gave an overview of the recent development around OpenID, such as the board election, new WGs, Dick Hardt going to Microsoft, etc.

One of the feature of IdCon is that it always coupled with drinking party afterwards. It is a very valuable socializing event.

The next IdCon (i.e., IdCon #5) will be hosted by NTT and expected to be around the cherry blossom time so that we can go on an outing for cherry blossom viewing afterwards.