Monthly Archives: November 2007

Inkscape Migrated to Launchpad

Yesterday I performed the migration of Inkscape's bugs from SourceForge.net to Launchpad. This was a full import of all their historic bug data – about 6900 bugs. As the import only had access to the SF user names for bug reporters, commenters and assignees, it was not possible to link them up to existing Launchpad users in most cases. This means that duplicate person objects have been created with email addresses like $USERNAME@users.sourceforge.net. If you are a Launchpad user and have previously filed or commented on Inkscape bugs, you can clean up the duplicate person object by going to the following URL and entering your $USERNAME@users.sourceforge.net address: https://launchpad.net/people/+requestmerge After following the instructions in the email confirmation, all references to the duplicate person will be fixed up to point at your primary account (so bug mail will go to your preferred email address rather than being redirected through SourceForge).

OpenID Attribute Exchange

In my previous article on OpenID 2.0, I mentioned the new Attribute Exchange extension. To me this is one of the more interesting benefits of moving to OpenID 2.0, so it deserves a more in depth look. As mentioned previously, the extension is a way of transferring information about the user between the OpenID provider and relying party. Why use Attribute Exchange instead of FOAF or Microformats? Before deciding to use OpenID for information exchange, it is worth looking at whether it is necessary at all. There are existing solutions for transferring user data such as FOAF and the hCard microformat. As the relying party already has the user's identity URL, it'd be trivial to discover a FOAF file or hCard content there. That said, there are some disadvantages to this method: Any information published in this way is available to everyone. This might be fine for some classes of information (your name, a picture, your favourite colour), but not for others (your email address, phone number or similar). The same information is provided to all parties. Perhaps you want to provide different email addresses to work related sites. The RP needs to make an additional request for the data. If we can provide the information as part of the OpenID authentication request, it will reduce the number of round trips that need to be made. In turn, this should reduce the amount of time it takes to log the user in. Why use Attribute Exchange instead of the Simple Registration extension? There already exists an OpenID extension for transferring user details to the RP, in the form of the Simple Registration extension. It has already been used in the field, and works with OpenID 1.1 too. One big downside of SREG is that it only supports a limited number of attributes. If you need to transfer more attributes, you basically have two choices: use some other extension to transfer the remaining attributes make up some new attribute names to send with SREG and hope for the best. The main problem with (2) is that there is no way to tell between your own extensions to SREG and someone else's which will likely create interoperability problems if when an attribute name conflict occurs. So this solution is not a good idea outside of closed systems. This leaves (1), for which Attribute Exchange is a decent choice. What can I do with Attribute Exchange? There are two primary operations that can be performed with the extension: fetch some attribute values store some attribute values Both operations are performed as part of an OpenID authentication request. Among other things, this allows: The OP to ask the user which requested attributes to send If the OP has not stored values for the requested attributes, it could get the user to enter them in and store them for next time. The OP could use a predefined policy to decide what to send the RP. One possibility would be to generate one-time email addresses specific…

Weird GNOME Power Manager error message

Since upgrading to Ubuntu Gutsy I've occasionally been seeing the following notification from GNOME Power Manager: I'd usually trigger this error by unplugging the AC adapter and then picking suspend from GPM's left click menu. My first thought on seeing this was "What's a policy timeout, and why is it not valid?" followed by "I don't remember setting a policy timeout". Looking at bug 492132 I found a pointer to the policy_suppression_timeout gconf value, whose description gives a bit more information. Apparently the timeout is designed to ignore spurious messages from the hardware after a resume -- you wouldn't want to process a left over "suspend" message immediately after resuming from suspend after all. This does bring up a few questions though: While ignoring "please suspend" messages shortly after performing a suspend makes sense, why ignore "please suspend" messages after an "on battery power message"? While messages from the hardware might be spurious, surely picking an option from GPM's menu is not. I guess such suspend requests are being mixed in with hardware suspend requests before the point where the policy timeout is checked.

Identifier Reuse in OpenID 2.0

One of the issues that the OpenID 1.1 specification did not cover is the fact that an identity URL may not remain the property of a user over time. For large OpenID providers there are two cases they may run into: A user with a popular user name stops using the service, and they want to make that name available to new users. A user changes their user name. This may be followed by someone taking over the old name. In both cases, RPs would like some way to tell the difference between two different users who present the same ID at different points in time. The traditional method of solving this problem is to assign two identifiers to a user: a human friendly identifier and a persistent identifier (e.g. a UNIX user ID, a database row ID, etc). At any point in time, the human friendly identifier will point to a particular persistent identifier, but over time the relationship may not hold. Whenever a human-friendly identifier is presented, it is transformed to its persistent counterpart before storage. With OpenID 1.1, Relying Parties are expected to use the canonicalised form of what the user enters to identify them. It is possible to redirect the human friendly identifier to a persistent one, but that is not particularly nice if you are trying to co-locate the user's home page and OpenID. OpenID 2.0: XRIs The only solution to this problem in earlier drafts of OpenID 2.0 was to use XRIs. When resolving an XRI, the resulting XRDS document includes a persistent identifier in the element. For example, resolving "=foo" gives us a canonical ID of "=!4EFC.841C.8012.E2F8". If a user logs in to an RP with the former, the RP will record the latter. This means the following: If the user stops paying their $12/year and someone else registers "=foo", that new user will have a different persistent ID so won't be able to assume the identity. If the user registers another XRI pointing at the same persistent identifier, it will be considered equivalent. OpenID 2.0: URL identifiers But if you want to use URLs as identifiers, how do you solve the problem? One solution that was shot down was to allow the <CanonicalID> element in the XRDS document for a URL OpenID. Apparently this was rejected because it would result in another round trip during the discovery process to find the endpoint for the persistent ID. Instead, a feature was added to help detect the case where an identifier was recycled. As part of the positive authentication response, an OP is allowed to modify the claimed ID to include a fragment URI component. If the identifier gets reassigned, the OP is expected to return a different fragment. This solves problem (1) but not problem (2). As it stands, the OpenID 2.0 specification doesn't provide much guidance in letting a user change their human friendly URL identifier while maintaining the same identity. A Solution One solution to this problem is to make use…