commit 32129a8966af7bcecc3708058be0f2eb5770e3ff
author Asim Shankar <ashankar@google.com> Thu Apr 28 02:38:07 2016 -0700
committer Asim Shankar <ashankar@google.com> Fri Apr 29 00:30:05 2016 +0000
tree 1ecadb6e481f0e081e40e3719da950c27c351aa7
parent 8b9601f728c9fd7744460a1d436b96859d68e0dc

services/identity/identityd: Remove unused services and code.

Prior to this patch, identityd provided three ways to get blessings:
(1) Vanadium RPC to the "macaroon" object
    This is used to obtain "user" blessings (<idp>:u:<userid>),
    using the protocol described in
    https://vanadium.github.io/designdocs/identity-service.html#user-blessing-flow
    typically via the 'principal seekblessings' command-line tool
(2) Vanadium RPC to the "google" object This also yields "user"
    blessings from a trusted chrome extension (wspr) or the "Vanadium
    Account" service in Android (a .apk separate from any user-facing
    application). The set of trusted applications were registered via the
    --google-config-chrome and --google-config-android flags.
(3) HTTPS: Exchanging an OAuth Access Token of an arbitrary application
    for a blessing. This results in "app" blessings, of the form:
    <idp>:o:<oauth client id>:<userid>

In both (2) and (3), there is no binding between the access token
and the channel (Vanadium RPC or HTTPS) to identityd. So, (2)
was adding no guarantees over (3).

With the emergence of (3), deletion of the Vanadium chrome extension and
no plans to use a separate .apk of "trusted code" running on Android
phones to manage Vanadium blessings, (2) has been rendered irrelevant.
It was a bunch of code, adding unnecessary complexity.

To re-iterate: There is no advantage to exchanging access tokens (or
IDTokens) for a blessing over Vanadium RPC vs. over HTTPS. Thus,
this patch just removes the former.

Change-Id: Id1c0e1ad06c7ee4231e8af91c041a16c4e6f4faa