After the meeting with our project supervisor yesterday, we decided to review the two architectures for online authentication mechanism. I’d like to present some of our findings and thoughts on these two in this post.
The first architecture is the one that we already had. In that model eID systems stays in the middle in the authentication processs between the eID Card Holder and the Relying Party. The system will be using a Java Applet to perform authentication with the eID Card Holder.
The second architecture that we proposed at yesterdays meeting. It keeps the eID Holder in the middle of the process, giving more control over what is happening. In this model the communication between the Relying Party and the eID System happens solely through the eID Card Holder. But for this to work we might have to use a local application or a browser plugin to perform many of the actions.
After some long discussions within the group members, we thought we should stick with the first design than the second one. I’d like to point out some of the points which led us to this decision.
Problems identified in the first design:
- Session handling method
- Tie up message flow
- Possible DoS attacks
How those could be solved:
- We can use session tokens accross a transaction, which could solve session handling and tie up message flow
- To prevent DoS attacks, there are many standard procedures. Using CAPTCHAs could be a very basic but an effective method in this. Also there are other measures that could be taken to prevent DoS attacks at system level.
Problems identified in the second design:
- Complexity on the Relying Party interms of Signing and Verifying Signs. This is a problems as we cannot expect every system developer how wants to use eID System to know and implement these complex tasks.
- Communication from the local application/plug-in will be a problem, unless we use HTTP. Also this needs certain installation and permission at user computer.
Also there is one important reason for deciding not to use the second design. The second design is very much identical to the Card Space specification. And these is already an implemention of this as WSO2 Identity Solution. Though there are significant differences from this and Project eID, following the same basic design would be like a duplication of systems.
So we have currently decided to use the our earliear design, but we can use any good features in the later design. I hope we could finalize on this by today evening. I’ll try to post an update on this by today night.