OpenID

Identifier Recycling

Support for re-using OpenID identifiers has become a goal for the OpenID authentication 2.0 specification. Several different mechanisms for accomplishing this goal have been proposed. In order to make a decision on how best to support identifier recycling, this page contains use cases related to identifier recycling, as well as descriptions of the proposed solutions.

Contents

Use Cases

  1. An OpenID provider wishes to recycle a URL identifier without making the URL any less desirable.
  2. A user obtains a recycled identifier and signs in to a site where the identifier was previously used. The user should be treated distinctly by the relying party from any previous owner of the identifier.
  3. A third party views content on a site that was created by a previous owner of a recycled identifier. The current owner of the URL wishes that the viewer can tell that the content was created by the previous owner. (Or at least not created by the current owner!)
  4. Software agents wish to differentiate between owners of an identifier without requiring the presence of any owner.
  5. User loses control of their identifier and wishes to prevent the new owner from accessing content that the old user had created using the identifier.
  6. User loses control of their identifier and wishes to regain access to protected resources associated with the identifier.

Cases 1, 2, 3, and 4 are the cases that the community agrees are the important ones to solve for OpenID 2.0. The other cases are included here because they are still desirable to solve, even if they are not necessary to solve for OpenID 2.0.

There is natural tension between use cases 1 and 3, because it is unlikely that a desirable identifier will contain sufficient context to allow a human being to differentiate it from the previous owner.

Proposed solutions

There have been several solutions to the problem of identifier recycling that have been proposed. In summary:

  • Use a URL fragment to differentiate owners of an identifier
  • Use a separate token to differentiate owners of an identifier
  • Use a persistent identifier as the database key, and use another that is more recognizable for display
  • Do not support an explicit mechanism for differentiating users (leave it up to provider policy how URLs are differentiated)

Each one of these techniques has benefits and drawbacks, and covers a different range of use cases. All of these solutions includes a part of the identifier that is nicely human-readable and another part that allows for software to differentiate between the identifiers.

Use Case 1 Use Case 2 Use Case 3 Use Case 4 Use Case 5 Use Case 6
URL Fragments ? + ? +
Separate Token + + ? ?
Persistent and Display Identifiers + ? + ? ?
Provider specific URL changes ? + + +

Notes

URL fragments 1, 3: This case is satisfied only when case three is not satisfied, and vice versa. The URLs become less desirable when the fragment is displayed, but the fragment must be displayed in order for third parties to determine which owner of an identifier is responsible for content.

Separate token 5, 6: These features would be supported if the token were a secret shared between the relying party, the user, and the provider.

Persistent identifier 2, 5, 6: Assuming that it's the display identifier and not the persistent identifier, this property holds. If it's the persistent identifier that was recycled, the user is indistinguishable from the previous owner.

Provider-specific URL changes 1: The URL that's issued is not exactly the same, so it can be argued that this property is not satisfied.

References

Comments

Care should be taken to avoid violating URIs don't change, a basic tenet of Architecture. -- Danny Ayers

Retrieved from "http://wiki.openid.net/Identifier_Recycling"