Maciej Pasternacki

Work done since last report

• Improved OpenID v1 compatibility in provider
• Moved general library functions to shared.lisp
• Few one-line fixes, cosmetics, docstrings, formatting etc
• (uncommited) Started work on MESSAGE structure, which will represent a single OpenID protocol message and will be one of base types after refactoring.

Problems

None whatsoever.

Plans for next half week

• Tests for shared.lisp functions
• Review existing tests, update or temporarily comment out outdated ones
• Finish MESSAGE structure and use it thorough prototypes
• Tests for MESSAGE class, if time permits

This report is a day late, but for good reason. For last few days I've been hunting bugs and edge cases for the provider prototype, and just finished it. It passes the server test at openidenabled.com and generally seems to work (at least for OpenID 2.0, 1.0 compatibility is not tested yet). So, it's just testing the 1.0 compatibility, and off to refactoring and polishing!

Work done since last report

• Fixed a bunch of minor bugs and typos
• Fixed the remaining bug in creating associations
• Support for successful response from the provider
• Support check_authentication and stateless mode
• Factor out responses to separate functions, introduce callbacks for user interaction

Problems

None, except the usual 90 / 10 Rule.

Plans for next half week

• 1.0 compatibility, probably
• Start refactoring: move out common parts of code to a single file
• If time permits, sketch an OO architecture and API for Relying Party

Work done since last report

• Finished and commited support for generating new associations
• In RP, display auth response verification errors
• Treat query parameters and addresses without trailing slash in RP return_to URI correctly
• Initial provider prototype (no positive assertions yet, only "cancel" and "setup_needed" responses)

Problems

Delay mentioned in earlier posts. I am working on catching up.

Plans for next half week

Finish OP prototype: construction of positive assertions, callback mechanism for end user interaction

This week, first potential user showed up on the devel list, and even sent the bug report (for trivial-utf-8, actually, and it's already fixed upstream). Wow! It seems that my stuff may be actually useful. ;)

Work done since last report

• Refactored association.lisp for more general association object construction and Diffie-Hellman negotiation
• Sorted out a bit general Provider skeleton design
• Implemented association support for OpenID Provider (still polishing, not commited yet)

Problems

Bits appearing where they should not. More specifically, I implemented the association support, but there are still bugs: in Diffie-Hellman key exchange (only in provider part, even though function for DH calculations is shared between OP and RP), the public value sent by provider is (usually, but not always) 129 bits long, instead of 128, with no apparent reason. Must be some mistake on my part in the modular arithmetic; I still have to hunt it down, and then the OP's associations are commitable.

Plans for next half week

I may not be able to give substantial time to project before Sunday – my girlfriend is moving out for her PhD, and I will need to help with packing and carrying boxes (and the house is in such a mess right now that it's getting hard to concentrate – and it's just the beginning of packing…). However, I hope I can at least handle the DH bug. I will make up for this from Sunday on. Summarizing, I plan to:

• Hunt down the Diffie-Hellman bug, commit OP associations
• Possibly some later parts of OP's conversations – authentication request, signatures – if time and circumstances permit.

Work done since last report

• Minor bugfixes in RP protocol
• Started work on OpenID Provider non-portable prototype (rough sketches, not commited yet).
• Choose reference relying party for initial tests: I use JanRain's python-openid, which I run directly from IPython

Problems

Plans for next half week

• Some frame for an endpoint
• Association support
• If tme permits, maybe rough authentication

Finally, the non-portable Relying Party is here. There is still a bit of duct tape here and there, and it cries for refactoring. The ID token deserves its own structure or class, and instead of global variables there should be a first-class Relying Party object with a bit of CLOS protocol and maybe callbacks (or maybe just inheritance and specialization will be enough). It may cry, but refactoring will have to wait; first, I wish to have non-portable OpenID Provider (or OP) prototype, so I can figure out common parts of the code and understand the protocol better.

Not all protocol options are explicitly supported yet: at least immediate check does not fit in the flow. This will be fixed with the refactoring and the first-class RP. There are some bugs left for sure, and unit tests aren't there yet – they'd need to be replaced during refactoring ayway.

Work done since last report

• Support for openid.invalidate_handle reply field and checking signatures directly with OP
• OpenID 1.x compatibility in RP
• Polished and commited whole Relying Party flow and Hunchentoot handlers
• Polished Authentication Response handling

Problems

Biggest and, I suppose, only problem since last report (or even two) was hitting the Ninety/Ten Rule: in last two weeks or so I did the last 10% of work, which took the other 90% of time. Debugging, corner cases, polishing… there is still some of these left to do, I think, but a prototype is working, and I'll take care of the details when I will do The Refactoring.

Plans for next half week

Start the non-portable prototype OpenID Provider. I won't try to precisely estimate how much would the provider prototype take; I think the safe bet would be two to three weeks.

Long time, no update; didn't write up for more than a week. My fault. The new code is still a mess, and every day I feel RP is just over the corner, and the next day, when it's done, I'll send the update. Doesn't seem to work this way. Probably in a few days at most, RP will be done; here's how it looks now:

Work done since last report

• Fixed minor bugs and annoyances: typo in ASDF:TEST-OP definition (TEST-OP didn't work at all before), shadowing import of CL:NULL (for unknown reason, Ironclad shadows NULL symbol), corner cases in random testing, EVAL-WHEN around DEFCONSTANTS, some typos
• Separated associations from ID alists. Association is not a part of an identity or of a verification process, as I first thought; it's basically a shared secret between Relying Party and an OpenID Provider. So, it had to be separated from ID flow and is now stored separately in its own structure. Information related to associations (valid association/session type lists) were also dropped from ID alists;
• Implemented generation and checking of message signatures,
• Implemented encoding alists to key-value form,
• Indirect request support, authentication request, indirect reply handling (NFY), some (not all) checks for positive assertion verification; no tests yet for these; not fully finished yet, but commited anyway;
• (uncommited) Hunchentoot handlers. They basically work, but are a bit of mess. I have the half-working Relying Party on my local development machine. After finishing the RP functionality, I can give the address to adventurous testers in private, if someone is interested in helping out.

Problems

Biggest problem was need to separate associations from IDs. It required quite a bit of refactoring and a change in my thinking about information flow within the protocol. Also, actual RP flow is a bit more tricky than I expected, and cleanly ftting protocol into HT while sustaining portability and separation between HTTP handlers anr protocol implementation isn't obvious.

Plans for next half week

• Finish the Relying Party. At last. The milestone is already a week late;
• Clean up the code: general bits, such as message formats or utility functions, not directly related to protocol flow, need to be put in a separate file instead of sticked near the first usage; also, there is a big need for docstrings (I want to write those later, since the internal API is quite a moving target at the moment);
• Tests. Most of work done since last report has no unit tests;
• External API.

• After finishing prototype RP, I will provide a real data structure (class or a struct) for the ID; maybe some more refactoring will be needed. After that (possibly in parallel with refactoring), I'll start the OpenID Provider part. This may be a bit easier than RP, since I understand the protocol much better than when I started the RP, and much common code is already written. The part when actual authentication takes place will be challenging – it will need to be pluggable and support whatever authentication scheme the library user imagines.