Labs/Apps/Verification

This page is for discussion of application verification algorithms, for use with an Open Web Application system.

Registration Requirements

A "registered" application is essentially a participant in a federated login system. The user proves their identity to some identity server (using whatever authentication technique is appropriate) and the identity is then relayed to the application.

The first requirement is therefore proof of user identity.

The verification flow must also provide proof-of-application ID, in addition to proof-of-identity. This requires that the application have some stable identifier that it can share with the store, which can be included with the verification information, through a secure channel.

The verification flow is subject to a number of attacks; a good introduction is in the OpenID 2.0 specification. The flow should be robust in the face of these attacks, typically by using signatures, nonces, and timestamps.

User identity and pseudonymity

In some designs, a stable and unique identity for the user would be included with the verification flow. Registration authorities have the option to make this identity unique on a per-application basis, or to provide a globally stable identity for the user.

In a production system, we encourage the use of per-application identities for users. The creation of globally stable user identities opens up a class of privacy-eroding data breaches, where user data is correlated between applications without the user's consent.

Proof of Purchase Requirements

To support paid applications, a registration authority must add the ability to prove to the application that payment has been made.

In many cases, this is implicit in the verification flow already discussed; an application ID can be included only if the user has paid for it, for example.

The authority may additionally add expiration dates to the assertion to support time-ranged purchases, or otherwise add attributes to indicate more details of the transaction.

Example: Use of OpenID 2.0

The OpenID 2.0 specification provides a federated login protocol that is field-tested, has good library support, and has good support for secure delivery of attributes to "relying parties" (which, in this case, would be apps).

The "authentication request" flow of OpenID can be used for verification. The checkid_setup mode is appropriate for this usage, since the user may need to provide credentials to the store. The "identifier_select" value will allow the user to log in to the store if, for some reason, they do not have a session already established.

discussion: should we augment the verify() method with an optional association handle?  

discussion: should we allow verify() to take a return_to parameter?

discussion: the cryptographic requirements of a direct store-to-app
communication are simpler than the OpenID use case.  In particular,
the application could use a pre-exchanged key pair to verify the
transaction.  Is the additional complexity of stateless verification,
or of full-on DH key exchange, worth the additional benefit?