Archive · Yadis wiki

Use case

A community web site requires all posters to be above 13 years old. While signing up, the user's page at the identity URL shows a request for an "age 13 or above" proof. It presents a list of compatible proofs the user has stored, or else a list of providers who the community is trusting. After supplying a proof, the user is either allowed to post anonymously, can supply more required details, or even sign up to enable SSO with the site.

Economy

The community site signs "trust-contracts" with 3rd parties, who could be banks or a new breed of "online identity providers". Some community sites are rich enough to pay the "proof"-provider per monthly traffic, while no-cost forums and blogs would need the end-user to pay. Providers could sell "proof"-issuing and validation, or give it as a bonus to frequent customers. Shopping sites that can perform online credit card verification could put a Yadis-server on top and start selling "age 18 or above" verifications.

Implementation

You need an agreed-on format for the "proofs" that are to be exchanged. Two simple models come to mind:

• Model 1. One dedicated Yadis URL for each proof. Presumably SSL-enabled, on a domain legally owned by the issuer.
• Model 2. A general Yadis URL with some kind of service specification, and a proof identifier which can be just a long string or key fingerprint or such.

There is also the more user-beneficial option of an extensive service which allows the user to request freshly issued proofs each time. Those would be verified by the interested party (community site) as in model 1 or 2. This should be the goal from the users point of view, since it prevents data aggregation (see separate section).

The simplest solution (model 1) only needs a Yadis-enabled server operated by the issuer. They give you a Yadis URL and a secret password, and you can use this to proove to other sites whatever the URL is guaranteed by the issuer to prove. And the community site would sign a contract with the issuer and then start consuming the proofs to store in their local database. But soon enough you'll want a more flexible solution that allows you to delegate to your "home identity" Yadis URL to manage those proof URLs and passwords. What you need is 3rd party delegation, mentioned here [1].

Anti-spam

Requiring a "13yo proof" before admitting anonymous posters also implies they have access to a real registered legal entity, like a real person or a company to hold liable for libel, spam, etc.

Risks

To avoid user data aggregation by affiliated sites without the user's consent, new identifiers could be issued at will (maybe with a small fee). Think virtual credit card numbers, which you create with a limited amount unique for each suspect shopping site, preventing over-charging and tracing if those details are spread or stolen. There will be a constant battle between identity thieves and users. The inconvenience to users, blocking old certificates at the issuer and getting new ones, might be a small effort, and might also teach a lesson in careful data handling. Some users might use one identity-provider for high-security things and another for the rest. Some identity-providers could also do free/low-cost re-issuing that conceals the original source of a proof. Like if your "age 13 or above" came from a shopping site, it might imply "has a credit card".