Limited scope: Web-only

OpenID Connect is limited to web applications; more precisely, it implements its mechanisms in terms of HTTP requests and responses so the client and service must implement HTTP to engage in a user-service relationship. Even if very much is available over web interfaces, this is very often a forced relationship, and not as natural as running it over a dedicated protocol for a given application. Finally, the security obtained through TLS may be less dependable than what can be achieved with other protocols, such as GSS-API and/or SASL.

It is likely that an OpenID Connect implementation can be founded on a general (meaning, protocol-agnostic) authentication framework such as Kerberos. The interesting result of doing that is that the local authentication solution then accellerates into a solution for the full-blown web. But it is important to note that the Internet comprises of much more than just the web; limiting the interactions between security realms to web traffic would be an incredible reduction of its power. It is a gross under-estimation of the potential of the Internet to state that a web-based authentication mechanism is sufficient to cover the future of the Internet, even if it happens to cover the usage patterns of today's majority.

Just to name an example, one might be given write access to a remote realm's LDAP node in the Global Directory, holding one's contact information and/or key material. And at some point we want general availability of chat and telephony to one's user@domain.name addresses, instead of being just a dependent of some privacy-milking corporation's infrastructure.

OpenID Connect component interaction

The main components in the OpenID architecture are:

• An End-User is the (human) whose identity is to be used as part of an OpenID Connect exchange;
• A Relying Party grants access to a resource if it can establish an acceptable identity using OpenID Connect;
• An OpenID Provider asserts the identity of the End-User when requested by the Relying Party.

The OpenID Provider sits in the realm of the End-User, not the Relying Party. In that sense, OpenID Connects effectively specifies a realm-crossover mechanism for identities assertions. Not surprisingly, identities incorporate the name of the remote realm, and this part is used by the Relying Party to resolve the OpenID Provider that is an authority to assert the claimed identity.

Because the OpenID Provider is part of the End-Users realm, it is possible for the End-User to choose a provider that will treat its privacy as desired; often, this means that the End-User can control what pieces of (partially) identifying information is released to the Relying Party.

OpenID Connect identities and discovery

The value added by OpenID Connect is its discovery method, that finds an OpenID Provider in the client's realm, which serves as the authority for a claimed End-User identity. This method can be used by the Relying Party if it has no out-of-band mechanism to find this server.

An identity for OpenID Connect is any URI, but a few abbreviated forms are possible; the form user@host.name is considered an abbreviation of the acct: scheme, and most other forms that lack a scheme are considered to be https: URIs.

Specifically for the ARPA2 project, where we use the user@host.name and host.name forms of identity, this is just what we need. So, as far as our interests are constrained to the web protocols HTTP and HTTPS, we can use OpenID Connect for cross-realm authentication.

The acct:user@host.name scheme is resolved through WebFinger, where the acct: URI is submitted as the resource to resolve, and the target web server is the host.name portion from the end user identity; this is a straightforward mechanism to ensure the authority of the WebFinger target over the claimed End-User identity. Note that a DNS-based discovery style for WebFinger would be possible, and could be helpful to overcome the limited scope of OpenID Connect (to web contexts). This has not currently been specified, but such a mechanism could be defined for each of the realm-crossover schemes described on this site.

The https://host.name scheme is also resolved through WebFinger, where the https: URI is submitted as the resource to resolve, and the target web server is the same host.name that occurs in the URI; again, this is a simple mechanism to assure authority of the WebFinger target over the claimed End-User entity: "yes, it is I". Although a DNS-based mechanism would seem useless because the resource is an HTTPS resource, it is worth noting that the identity does not actually need lookups over the URI schemes that they are using. A connection over SIP may use these identities without a need or desire to implement HTTPS.

Unleashing OpenID Connect to the rest of the Internet

It has been stated in the previous sections already; limiting a realm-crossover mechanism to cover just the web reflects a needlessly limited view on a general problem that applies to all protocols.

If OpenID Connect is to become more widely available, it specifically would need to support discovery mechanisms that are similar to WebFinger, but not constrained to web applications.

The most interesting solutions for this are, and now we follow the general approach of ARPA2.

Both services and users can be resolved in DNS, as long as this does not publish the actual usernames, as these might also be used as contact addresses, and because it is generally undesirable to make such addresses iterable or otherwise public. This means that a pattern should contain a variable for the username component as part of the URI generated for discovery of the OpenID Provider.

Multiple discovery methods could be offered in parallel, so a switching mechanism in DNSSEC-protected DNS is helpful to redirect the discovery attempt to the actual identity provider location; this is probably done best with an NAPTR record. This path would also enable the inclusion of phone numbers as identities, following the ENUM scheme.

Note that this NAPTR record would be a more general alternative for the WebFinger strategy. The current WebFinger specification could serve as a fallback default, and when NAPTR records are specified they are likely to be one of the entries; however, there may also be other facilities, and it is possible to provide a preferred order for these. This provides an introduction path for other realm-crossover schemes such as Kerberos5 or Moonshot -- and it explicitly mentions which are supported for a claimed identity.

At least one resolution method is highly interesting as an alternative to HTTP, and that is LDAP, to be used as part of the Global Directory. LDAP has a labeledURI attribute type, which currently lacks an attribute option to match the rel tags used in the HTTP World, but that is easily added, possibly together with an LDAP Control to signal support and desire of this additional piece of information.