• XriOpenIdIntegration

Introduction

This page discusses issues, guidelines, and recommendations for integrating XRI resolution with the OpenID framework, specifically the [http://www.openid.net/specs.bml OpenID 2.0 authentication].

Open Issues

Following are the key issues being discussed between OpenID and XRI developers.

1. Use of XRI Proxy Resolution

Currently many OpenID Relying Party (RP) implementations use XRI proxy resolution from http://xri.net. The open issues are:

• How long this should continue - should this be the standard practice for OpenID 2.0 implementations, or should they incorporate local XRI resolution libraries as soon as possible?
• How soon with local XRI resolver libraries be available in languages other than Java?
• What specific set of Heraldry committers should work together to see this through smoothly?

2. OpenID Service Endpoint Selection

The XRI Resolution 2.0 specification (currently at [http://www.oasis-open.org/committees/download.php/17293 Working Draft 10] but Working Draft 11 is underway) has normative specifications for service endpoint (SEP) selection based on parameters passed to an XRI resolver (either via a local API to a local resolver or as http query parameters to a proxy resolver like xri.net).

Most if not all current OpenID RP implementations do not use these SEP selection rules, but instead simply parse out an OpenID SEP using the Type element value specified in the OpenID 2.0 specification (formerly the Yadis specification). The open issues are:

• When should OpenID RP implementations begin using standardized SEP selection?
• Should they rely on a local XRI resolver library to do this for them?
• In the meantime, are there any changes recommended to how an OpenID RP implementation should select an OpenID SEP?

3. CanonicalID Trust Rules

XRI resolution infrastructure has a fundamental feature called CanonicalIDs that enable multiple XRI synonyms to be mapped to a persistent identifier that will never be reassigned. This is the "persistent key" that should be used by any service provider to index/access the resources the service provider offers on a user's behalf. This overcomes the issue of URLs being reassignable.

Kevin Turner had a long email thread with the XRI Resolution 2.0 editors (Drummond, Gabe, Les, Wil, Steve) about how OpenID RPs could verify the CanonicalID asserted in an XRD if the XRD was produced by anything other than a root XRI authority (such as = or @). The open issues are:

• Will these CanonicalID trust verification rules be going into XRI Resolution 2.0 Working Draft 11?
• In OpenID AuthN 2.0 code, should the OpenID RP code or the XRI resolver code do this CanonicalID trust verification? How should it be handled in OpenID AuthN 3.0 code?

4. Synonym Handling

XRI infrastructure implicitly handles the mapping of multiple reassignable XRI synonyms (i-names) to a CanonicalID (i-number). This feature appears roughly analogous to the OpenID delegate feature, except OpenID delegate URLs are designed to handle the problem of a user able to keep the same URL while switching OpenID IdPs, while XRI synonyms handle the reverse problem of being able to keep the same CanonicalID if you change one or more i-names (as people and companies sometimes need to do).

The open issues are:

• How should OpenID 2.0 code bases deal with this XRI feature, if at all?
• How should future OpenID code bases deal with it? In other words, what's the best overall architecture for dealing with both URL and XRI synonyms in the context of OpenID user-centric identity infrastructure?