From Yadis

8 Possible Future Work

8.1 Alternative Identifiers

There has been some debate about whether URLs make good personal identifiers. For better or worse, Yadis is based on HTTP and is thus inseparably bound to URLs, but this doesn't mean that alternative identifiers could not be layered on top of the URL-space.

Work is already underway on XRI, which attempts to provide a more human-friendly layer which ultimately resolves to a URL. The intention of the Yadis Specification is to include URIs and Yadis IDs.

There has also been some discussion about coming up with a convention for mapping an email-style identifier onto a URL.

Neither of these additions affects the core Yadis spec, which must always use identifiers that are resolvable to URLs. Therefore other parties are free to invent such systems which can then can used with Yadis once they become pervasive. Since Yadis is a layer of abstraction above other identifiers, this will then make such identifiers available to users of the underlying sign-on protocols.

8.2 A further exploring of this idea

Bill.Barnhill 19:32, 5 November 2005 (PST) Communitivity

My apologies if this is the wrong page to post this on. I've been thinking about Yadis and it seems to me that you could get a lot of benefit from using a URN instead of a URL, with an abbreviation to reduce the typing needed.

Usage scenario:

1. User sees "My ID:" and types in the abbreviated URN
   • For LID 2.0: 'lid2:' followed by canonical LID2.0 URL minus beginning http://
   • For XRIs: 'xri:' followed by the XRI minus beginning xri:// if any
   • For OpenID: 'openid:' followed by OpenID URL minus beginning http://
   • For anything else it's left as is
2. System prepends urn:x-id: to the entered text if one of known ID types (LID2.0, XRI, OpenID), and stores in my_name
3. System gets list of supported Yadis plugins
4. For each plugin, the System calls plugin.match(my_name) until either a true is returned from the call or there are no more plugins
5. If no more plugins and no match call returns true then some kind of error message must be displayed to the user
6. Otherwise, the system calls either plugin.metaIdentityDOMFor(my_name, empty DOM Document) or plugin.metaIdentitySAXFor(my_name, SAX 2 handler) or plugin.metaIdentityServices(my_name). The last one would return an Iterator over the services. The plugin called is the first one to return a true from the match call.
7. The plugin passes back to the system via SAX or DOM the XML doc of application/x-meta-identity #:
8. At this point the system has the services and from here on the proposed steps would be the same as in the current Yadis spec. Since authentication is delegated what could be done here is to call plugin.authenticate(my_name, Params iterator/array/dictionary) for the plugin that matched my_name.

Benefits:

• Allow easier extension to non-http based schemes, such as XMPP. Is there truly a need to be tied to HTTP, especially if you create an XML format for the application/x-meta-identity document?
• Easier for individual identity system architects to provide a Yadis plugin for their system
• Does not have to have the fragility of URLs

Problems:

• URNs are really designed for an identifier that never changes, and none of the above are unchanging, except for perhaps an XRI with all persistent segments. If we relax it to be reasonably unchanging then the above should work
• URN namespaces are a managed resource set, per RFC 3405, and to make urn:x-id into urn:id a formal URN namepace request should be filed.
• It means a little extra typing. Yadis.org could manage a set of accepted shortcuts,such as recognizing lids by their authority starting with lid. and HXRIs by their authority starting with xri.

Nurm 11:44, 29 October 2006 (PST)

I've been thinking about creating a service that will do OpenID validation of an XMPP address (via XEP-0070). This would extend the validation of XMPP address to any OpenID consumer. It sounds like I should be looking at Yadis so that both OpenID and LID mechanisms would be 'forwardable' to XMPP. (That way we support consumers from both standards)

Usage example: An OpenID URL of: http://openid.xmpp.net/[email protected] would validate with [email protected]'s XMPP account.

8.3 Another idea

Bill.Barnhill 19:44, 5 November 2005 (PST) Communitivity

• This would require further discussion and analysis to see if benefit was worth it, but a special query param (ok those words don't bode well) to hold an encoded SAML assertion. This would more be useful from a system standpoint as I seriously doubt any user will type that in. I think what I'm thinking is a browser that adds 1 or 2 headers to each request:
  • x-metadata-identity.whoami=your Yadis urn/url
  • x-metadata-identity.assertion=Assertion from Identity Provider