I'm sitting in a session on webfinger, OpenID Connect, and discovery session. Discovery is a the process of turning a small piece of information (like a user ID) into the URLs and APIs needed to service some specific request. For example, say I tell you my email address is windley@gmail.com, how do you find my profile? Of course, as long as we're talking about one site, like Google, we can just hard code that translation. But how can the discovery problem be generalized?

That's the goal of Webfinger: WebFinger is about making email addresses more valuable, by letting people attach public metadata to them. You can try it yourself at webfinger.org (try it with your GMail address, for example).

There's also the related problem of how to know, for some particular host, where to get the webfinger data. That's the job of the host-meta file, a well-known URL proposal.

For example the host-meta data for Google is here:

http://gmail.com/.well-known/host-meta

and it returns

<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0' 
     xmlns:hm='http://host-meta.net/xrd/1.0'>
  <hm:Host xmlns='http://host-meta.net/xrd/1.0'>gmail.com</hm:Host>
  <Link rel='lrdd' 
        template='http://www.google.com/s2/webfinger/?q={uri}'>
    <Title>Resource Descriptor</Title>
  </Link>
</XRD>

This tells us that we can get data about a GMail account from the URL

http://www.google.com/s2/webfinger/?q={uri}

by substituting the GMail address for {uri}. So we can get my webfinger data from

http://www.google.com/s2/webfinger/?q=windley@gmail.com

This URL returns the extensible resource descriptor (XRD) as follows:

<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
  <Subject>acct:windley@gmail.com</Subject>
  <Alias>http://www.google.com/profiles/windley</Alias>
  <Link rel='http://portablecontacts.net/spec/1.0' 
        href='http://www-opensocial.googleusercontent.com/api/people/'/>
  <Link rel='http://portablecontacts.net/spec/1.0#me'
        href='http://www-opensocial.googleusercontent.com/api/people/103887646945247867113/'/>
  <Link rel='http://webfinger.net/rel/profile-page' 
        href='http://www.google.com/profiles/windley'  
        type='text/html'/>
  <Link rel='http://microformats.org/profile/hcard' 
        href='http://www.google.com/profiles/windley'  
        type='text/html'/>
  <Link rel='http://gmpg.org/xfn/11'  
        href='http://www.google.com/profiles/windley'  
        type='text/html'/>
  <Link rel='http://specs.openid.net/auth/2.0/provider'  
        href='http://www.google.com/profiles/windley'/>
  <Link rel='describedby'  
        href='http://www.google.com/profiles/windley'  
        type='text/html'/>
  <Link rel='describedby'  
        href='http://www.google.com/s2/webfinger/?q=windley%40gmail.com&fmt=foaf'  
        type='application/rdf+xml'/>
</XRD>

If you look closely, you'll see that there is a subject, and alias, and a lot of URLs that are tagged in ways that tell you categorically what kind of thing they return about the subject. For example, the entry with

rel=http://microformats.org/profile/hcard

tells you where to get HCard data about me.

You might notice that there's a lot of XML here. There are proposals to turn this into JSON, such as JRD, the JSON resource descriptor. Lots of discussion about why this is better, easier, and so on.

One extension is to allow for access tokens to get non-public information. For example, you can get my publicly available information from the profile URL, but what if I've been to your site or app and allowed you access to non-public data? Can you get it using this mechanism. What's the standard for specifying how to pass the OAuth tokens, for example.

So, if I understand correctly, OpenID Connect is a variation on Webfinger that uses JSON, extends it in important ways, and allows OpenID (and other systems) to dynamically put relevant links to services on sites without hard coding them. This allows small players to compete in the NASCAR game. Most service providers won't be big enough to get their button hard coded on a site, discovery allows them to get dynamically added when the site knows that they're relevant.