Archive for April, 2006

50-year iname price increasing

Sunday, April 30th, 2006

Hot off the press: 50-year iname prices will increase May 8.

Get your inames and gift codes for $25 while you can. (A gift code at $25 will be the least expensive way to register an unclaimed XNS name when they become available after the global launch.)

=inamers

why get an i-name?

Tuesday, April 25th, 2006

We got the following questions and thought the answer was worth blogging

I had to verify my email address to send mail to the author of a blog I subscribe to. So I am ready to consider getting an i-name, but why would I choose an i-name over any of the other identity services out there? What is the chance that i-name will become the accepted standard? Can I consider i-name a replacement for email certificates? If not, what is the difference?

These are great questions. Following we do our best to answer without resorting to technical mumbo jumbo.

First, it will be helpful to clarify what an i-name is; it’s simply an identifier - a string of characters that you register - and the mumbo jumbo that let’s the name be used with all kinds of services.

When you register an i-name at 2idi today, you get two services:

1] Authentication service - authentication lets you prove you are the owner of the iname by entering your password. Once authenticated you can simply present your iname to other iname enabled service providers and they can verify that you are already logged in by asking your authentication service. Note that they don’t need your password to do this.

2] Contact service - a web page that let’s people send you messages provided they authenticate themselves. As you experienced, you were able to authenticate by verifying your email address.

Both of these services are provided by 2idi today and are integrated into the 2idi ibroker code itself. However, at the upcoming global launch these services can just as easily be provided by other service providers. Your ibroker (where you register and manage your iname) will always offer some essential services (such as authentication), but they will also let you provision whatever other services you want. This is a key value of the iname/ibroker. You can use this ability to augment or replace services your ibroker offers with ones you prefer; for instance a better authentication service than your ibroker provides. The services you can manage under your iname are extensible and distinct from the iname itself. Your iname is simply your identifier (and the mumbo jumbo).

So, back to the questions. You’re wondering about the value of the iname identifier, the services that go with it, and the chances that it becomes *the* accepted standard.

Thanks to Kim Cameron, the conversation in the internet identity space is now framed in the generally accepted concept of an identity metasystem - an interoperable mix of different identity standards and protocols. Fundamental to the metasystem concept is the notion that any true identity solution needs to consist of interoperable approaches so that we don’t get trapped in identity “silos”.

What’s important at this juncture is not whether any particular standard is going to *win* and be *the* standard, but whether it is going to be interoperable with the others. Inames were developed with interoperability in mind, they don’t replace anything, they are compatible with *all* other identifiers (they are sometimes referred to as a meta-identifier), and they create new capabilities. The proof of inames’ value still has to be demonstrated, but their ability to be interoperable is clear:

Inames are a part of the Yadis project, an open source, open protocol initiative to create interoperability between simple authentication services including LID and OpenID. Inames are interoperable with Liberty and Microsoft’s infocards. And at launch, inames will have SAML based authentication as well.

So, inames won’t be *the* standard, but they are *a* standard that will work with the others. How valuable they become still needs to be proven in the marketplace where inames need to demonstrate their unique value within the identity metasystem.

Lastly, the iname is not a replacement for email certificates, but it’s possible for your iname to point to all kinds of certificates that you might want to use; certificates can be “just another service”.

As to whether you should purchase an iname, that is up to you. The specially priced 50-year inames at 2idi were priced to make the gamble worthwhile. But you don’t have to buy an iname to use the iname services - you can also get a free iname at one of the community sites.

=inamers

inames.net site now online

Monday, April 24th, 2006

We just noticed that the nifty new inames site inames.net is now online. Check it out!

=inamers

tip: use gift codes (even after the launch)

Monday, April 24th, 2006

Most folks know you can register inames at 2idi. But few seem to be aware that you can also purchase iname gift codes.

Gift codes are a simple “token” you can use to register an i-name. The idea for gift codes was (as the name implies) to enable gift-giving, but they also can be used in a couple other ways.

If you’re going to purchase more than one iname, you can use your credit card once to buy gift codes. Then, whenever you feel like it, you can redeem the gift codes one at a time to register an iname without having to use your card again.

The ability to purchase a gift code today and use it later can be used to “lock-in” the special 50-year price today and then redeem it for an iname after the launch. For anybody interested in XNS reserved names this provides a means to get an iname that won’t be available until the after the launch but do it at today’s prices.

As an example of how the gift codes work, here’s a real, live gift code for the first person who reads this blog and redeems it for an iname: B6Bi39W (just paste it into the form at 2idi)

=inamers

(Note that gift code sales will end on 5/31 as the transition to global launch begins)

iname launch update updated

Monday, April 24th, 2006

As reported here last week the iname launch target of May 1 was going to be delayed at least a few weeks.

The new consensus target date from the various project leaders is for a June 13 launch. From our perspective this is doable but still aggressive. We’ll continue to keep folks posted.

An important aspect of this new date is that it implies an end to the “early iname” program of May 31st. This is because the launch project has 2 weeks set aside for the transition from “2idi” only to full “multi-broker” infrastructure. We’re not sure why it takes that long, and hopefully it won’t.

At any rate, we’re hoping that authentication and contact pages will continue to work during that transition period. We’ll try to learn more about the transition period and summarize it here.

=inamers

iname launch update

Monday, April 17th, 2006

The latest word on the upcoming iname “launch” is that it will definitely be delayed at least a few weeks from it’s May 1 schedule. Late May to early June is the new timeframe.

Watch this space for updates.

if you’re into details: global iname registry specs

Saturday, April 15th, 2006

Here’s an email from Drummond Reed, just sent to the Identity Commons Community mail list, announcing a major chunk of documents that define services and terms for the global iname registry. We’re posting it here in case folks are interested. For those that don’t read through the docs, we’ll post any juicy bits we discover. Now, over to Drummond:

“Members of the GSS Comment List (with apologies for cross-posting to the Identity Commons Community List and Identity Commons Developer’s List):

After many months of work it is a pleasure to announce that Release Candidate 1 of the XDI.org Global Services Specifications (GSS) has been uploaded to the GSS wiki at:

http://gss.xdi.org/

The former wiki-based GSS specs have now been replaced by a single page listing of the GSS documents in PDF and Word format. This list includes the main GSS specification (including Appendix A – Definitions) followed by listings for each of the rest of the Appendicies (B through N) as separate documents.

What has been posted so far is:

* The main GSS specification document including Appendix A (68 pages)
* Appendix N: GRSP Service Level Agreement (5 pages)

12 additional appendicies, which are primarily legal documents, remain to be posted. These are currently in the final stages of editing by the legal team (Scott Blackmer of XDI.org, Brian Lewis of Cordance, and Jeff Neuman of NeuStar). Each will be posted as soon as it is ready, with the goal of all documents being in review by the XDI.org trustees by the end of this week.

We strongly encourage review and feedback as quickly as possible as integration testing has begun in preparation for the launch of the Global Registry System (GRS). Please send comments to any of the lists cc’d above, or post them directly on the GSS wiki.

Thank you,

=Drummond (http://xri.net/=drummond.reed)