Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 // Definitions for CryptAuth API calls. | |
| 2 // Generated from server definitions. Do not edit. | |
|
Ilya Sherman
2014/10/06 21:15:59
nit: We should probably add a copyright stanza to
Tim Song
2014/10/07 00:06:07
Done.
| |
| 3 syntax = "proto2"; | |
| 4 | |
| 5 package cryptauth; | |
| 6 option java_package = "com.google.api.services.cryptauth"; | |
|
Ilya Sherman
2014/10/06 21:15:58
nit: Do we want to keep this line in the Chromium
Tim Song
2014/10/07 00:06:07
Done.
| |
| 7 | |
| 8 option optimize_for = LITE_RUNTIME; | |
| 9 | |
| 10 // Wait for the specified transaction to change state. | |
| 11 message AwaitTxRequest { | |
| 12 // An opaque (random) identifier for this transaction. | |
| 13 optional bytes tx_id = 1; | |
| 14 } | |
| 15 | |
| 16 // If the transaction has completed, a token will be returned encapsulating the | |
| 17 // result of the transaction. The token is opaque, and can be decoded by using | |
| 18 // the CompleteTx backend query. | |
| 19 message AwaitTxResponse { | |
| 20 // An opaque token encoding the transaction result. | |
| 21 optional bytes tx_token = 1; | |
| 22 | |
| 23 // Identifies what kind of resource this is. Value: the fixed string | |
| 24 // <code>"cryptauth#awaitTxResponse"</code>. | |
| 25 optional string kind = 2; | |
| 26 } | |
| 27 | |
| 28 // Device information provided to external clients that need to sync device | |
| 29 // state. | |
| 30 message ExternalDeviceInfo { | |
| 31 // A cryptographic public key associated with the device. | |
| 32 optional bytes public_key = 1; | |
| 33 | |
| 34 // A user friendly (human readable) name for this device. | |
| 35 optional string friendly_device_name = 2; | |
| 36 | |
| 37 // If available, the device's bluetooth MAC address | |
| 38 optional string bluetooth_address = 3; | |
| 39 | |
| 40 // Whether or not this device can be used as an unlock key | |
| 41 optional bool unlock_key = 4; | |
| 42 | |
| 43 // Whether or not this device can be unlocked | |
| 44 optional bool unlockable = 5; | |
| 45 } | |
| 46 | |
| 47 // Request for a list of devices that could be used as Unlock Keys, optionally | |
| 48 // requesting a callback over bluetooth (for proximity detection). | |
| 49 message FindEligibleUnlockDevicesRequest { | |
| 50 // A bluetooth MAC address to be contacted if a device that may be eligible | |
| 51 // for unlock is nearby. If set, a message will be pushed to all eligible | |
| 52 // unlock devices requesting that they contact the specified MAC address. If | |
| 53 // this field is left unset, no callback will be made, and no message will be | |
| 54 // pushed to the user's devices. | |
| 55 optional string callback_bluetooth_address = 2; | |
|
Ilya Sherman
2014/10/06 21:15:59
Is it intentional that the field with tag "1" is o
Tim Song
2014/10/07 00:06:07
Yes, it's intentional. There are fields used only
| |
| 56 | |
| 57 // Identifies what kind of resource this is. Value: the fixed string | |
| 58 // <code>"cryptauth#findEligibleUnlockDevicesRequest"</code>. | |
|
Ilya Sherman
2014/10/06 21:15:58
Hmm, why do we have this field at all, if it has a
Tim Song
2014/10/07 00:06:07
This value is used if you just have a serialized b
| |
| 59 optional string kind = 3; | |
| 60 } | |
| 61 | |
| 62 // Response containing a list of devices that could be made Unlock Keys | |
| 63 message FindEligibleUnlockDevicesResponse { | |
| 64 // Devices that could be made Unlock Keys (even if they aren't enabled yet) | |
| 65 repeated ExternalDeviceInfo eligible_devices = 1; | |
| 66 | |
| 67 // Devices that cannot be made unlock keys, and reasons for this. This list | |
| 68 // will not contain any non-gms core devices, even though these are also not | |
| 69 // eligible to be unlock keys. | |
| 70 repeated IneligibleDevice ineligible_devices = 2; | |
| 71 | |
| 72 // Identifies what kind of resource this is. Value: the fixed string | |
| 73 // <code>"cryptauth#findEligibleUnlockDevicesResponse"</code>. | |
| 74 optional string kind = 3; | |
| 75 } | |
| 76 | |
| 77 // Request to complete a device enrollment. | |
| 78 message FinishEnrollmentRequest { | |
| 79 // The enrollment session identifer from the <code>setup</code> response. | |
| 80 optional bytes enrollment_session_id = 2; | |
| 81 | |
| 82 // An encrypted payload containing enrollment information for the device. | |
| 83 optional bytes enrollment_message = 3; | |
| 84 | |
| 85 // A Diffie-Hellman public key for the device, to complete the key exchange. | |
| 86 optional bytes device_ephemeral_key = 4; | |
| 87 } | |
| 88 | |
| 89 // Response indicating whether a device enrollment completed successfully. | |
| 90 message FinishEnrollmentResponse { | |
| 91 // Status should be OK if the request was successful. | |
| 92 optional string status = 1; | |
| 93 | |
| 94 // A detailed error message if there was a failure. | |
| 95 optional string error_message = 2; | |
| 96 | |
| 97 // Identifies what kind of resource this is. Value: the fixed string | |
| 98 // <code>"cryptauth#finishEnrollmentResponse"</code>. | |
| 99 optional string kind = 5; | |
| 100 } | |
| 101 | |
| 102 // Used to request devices that have a specific feature. | |
| 103 message GetDevicesForFeatureRequest { | |
| 104 // Requests those devices that support the specified DeviceFeature | |
| 105 optional string device_feature = 2; | |
|
Ilya Sherman
2014/10/06 21:15:58
Is there a list of valid features? (Seems like th
Tim Song
2014/10/07 00:06:07
I'm not sure why the generator turns enums into st
| |
| 106 } | |
| 107 | |
| 108 // Devices that have a certain feature, as returned by the GetDevicesForFeature | |
| 109 // RPC. | |
| 110 message GetDevicesForFeatureResponse { | |
| 111 // A (possibly empty) list of devices supporting the requested featur | |
|
Ilya Sherman
2014/10/06 21:15:59
nit: "featur" -> "feature"
Tim Song
2014/10/07 00:06:07
Done. I'll also change this on the server-side so
| |
| 112 repeated ExternalDeviceInfo result_sets = 1; | |
| 113 | |
| 114 // Identifies what kind of resource this is. Value: the fixed string | |
| 115 // <code>"cryptauth#getDevicesForFeatureResponse"</code>. | |
| 116 optional string kind = 2; | |
| 117 } | |
| 118 | |
| 119 // This request is sent by the login page to obtain one challenge session for | |
|
Ilya Sherman
2014/10/06 21:15:58
What is the "login page"? The ChromeOS sign-in sc
Tim Song
2014/10/07 00:06:06
I think this refers to the GAIA login page.
Ilya Sherman
2014/10/07 01:09:08
Hmm, do we show a GAIA login page as part of EasyU
Tim Song
2014/10/07 17:05:42
We don't use this in Easy Unlock, but it might be
Ilya Sherman
2014/10/07 20:46:41
Hmm. My preference would be to not include messag
Tim Song
2014/10/14 00:30:24
Okay I removed the unused APIs.
| |
| 120 // each of the user's devices. Challenges can be signed by the user's device as | |
| 121 // part of a login assertion. | |
| 122 message GetLoginChallengesRequest { | |
| 123 // Protocol type to be used with the requested login challenges. | |
| 124 optional string protocol_type = 3; | |
| 125 | |
| 126 // Used to request a login challenge for a particular device, specified by its | |
| 127 // public key | |
| 128 optional bytes user_public_key = 5; | |
| 129 } | |
| 130 | |
| 131 // Response encapsulating a list of login challenges (together with their | |
| 132 // metadata). | |
| 133 message GetLoginChallengesResponse { | |
| 134 // List of login challenges (with associated metadata) | |
| 135 repeated LoginChallengeInfo login_challenge_infos = 3; | |
| 136 | |
| 137 // Identifies what kind of resource this is. Value: the fixed string | |
| 138 // <code>"cryptauth#getLoginChallengesResponse"</code>. | |
| 139 optional string kind = 4; | |
| 140 } | |
| 141 | |
| 142 // Request for a listing of a user's own devices | |
| 143 message GetMyDevicesRequest { | |
| 144 // Return only devices that can act as EasyUnlock keys. | |
| 145 optional bool approved_for_unlock_required = 2; | |
| 146 | |
| 147 // Identifies what kind of resource this is. Value: the fixed string | |
| 148 // <code>"cryptauth#getMyDevicesRequest"</code>. | |
| 149 optional string kind = 3; | |
| 150 } | |
| 151 | |
| 152 // Response containing a listing of the users device's | |
| 153 message GetMyDevicesResponse { | |
| 154 // A listing of all sync-able devices | |
| 155 repeated ExternalDeviceInfo devices = 1; | |
| 156 | |
| 157 // Identifies what kind of resource this is. Value: the fixed string | |
| 158 // <code>"cryptauth#getMyDevicesResponse"</code>. | |
| 159 optional string kind = 2; | |
| 160 } | |
| 161 | |
| 162 // A device that the server thinks is not eligible to be an unlock key, and the | |
| 163 // reason for this. | |
| 164 message IneligibleDevice { | |
| 165 // The device that is not eligible to be an unlock key. | |
| 166 optional ExternalDeviceInfo device = 1; | |
| 167 | |
| 168 // The reasons why the server thinks it is not an unlock key. NOTE: for now, | |
| 169 // this list of reasons will contain exactly one element. It is a repeated | |
| 170 // field because, in principle, there can be more than one reason that makes a | |
| 171 // device not eligible to be an unlock key, and we want to be able to add | |
| 172 // multiple reasons in the future. | |
| 173 repeated string reasons = 2; | |
| 174 } | |
| 175 | |
| 176 // A login challenge together with its metadata | |
| 177 message LoginChallengeInfo { | |
| 178 // Protocol type to be used with this login challenge | |
| 179 optional string type = 1; | |
| 180 | |
| 181 // Challenge to be signed by the device | |
| 182 optional bytes challenge = 2; | |
| 183 | |
| 184 // Key handle that the device registered with | |
| 185 optional bytes key_handle = 3; | |
| 186 | |
| 187 // Used to identify this challenge to the server | |
| 188 optional bytes challenge_session_id = 7; | |
| 189 | |
| 190 // Application id for which the device key is supposed to work | |
| 191 optional string application_id = 8; | |
| 192 } | |
| 193 | |
| 194 // Encapsulates a transaction reply, sent from the user's device. The details of | |
| 195 // the transaction and the reply are encrypted. | |
| 196 message ReplyTxRequest { | |
| 197 // Encrypted transaction ledger, containing the original prompt request and | |
| 198 // the user's response. | |
| 199 optional bytes secure_tx_ledger = 1; | |
| 200 } | |
| 201 | |
| 202 // Requests to send a "tickle" requesting to sync all of a user's devices now | |
| 203 message SendDeviceSyncTickleRequest { | |
| 204 // Identifies what kind of resource this is. Value: the fixed string | |
| 205 // <code>"cryptauth#sendDeviceSyncTickleRequest"</code>. | |
| 206 optional string kind = 2; | |
| 207 } | |
| 208 | |
| 209 // Contains information needed to begin a device enrollment. | |
| 210 message SetupEnrollmentInfo { | |
| 211 // Type of protocol this setup information was requested for | |
| 212 optional string type = 1; | |
| 213 | |
| 214 // A session identifier to be used for this enrollment session. | |
| 215 optional bytes enrollment_session_id = 2; | |
| 216 | |
| 217 // A Diffie-Hellman public key used perform a key exchange during enrollment. | |
|
Ilya Sherman
2014/10/06 21:15:59
nit: "used perform" -> "used to perform"
Tim Song
2014/10/07 00:06:07
Done.
| |
| 218 optional bytes server_ephemeral_key = 3; | |
| 219 } | |
| 220 | |
| 221 // Requests information needed to begin a device enrollment. | |
| 222 message SetupEnrollmentRequest { | |
| 223 // Deprecated. See <code>application_id</code> | |
| 224 optional string origin = 2; | |
|
Ilya Sherman
2014/10/06 21:15:59
nit: Can this field be annotated as "[deprecated=t
Tim Song
2014/10/07 00:06:07
I think this is a "soft" deprecation rather than a
| |
| 225 | |
| 226 // Type(s) of protocol supported by this enrolling device (e.g. "gcmV1") | |
| 227 repeated string types = 3; | |
| 228 | |
| 229 // Indicates whether a legacy crypto suite must be used with this device. | |
|
Ilya Sherman
2014/10/06 21:15:58
Is there a specific legacy crypto suite that's bei
Tim Song
2014/10/07 00:06:07
No idea...
| |
| 230 optional bool use_legacy_crypto = 4; | |
| 231 | |
| 232 // A URL describing which application facets this enrollment can be used (see | |
|
Ilya Sherman
2014/10/06 21:15:58
nit: I don't understand this sentence :/
Tim Song
2014/10/07 00:06:07
This seems to be something in the early stages of
| |
| 233 // http://go/appid). | |
|
Ilya Sherman
2014/10/06 21:15:58
nit: Can we point to a publicly-accessible URL?
Tim Song
2014/10/07 00:06:07
I don't think this concept is fully implemented ye
| |
| 234 optional string application_id = 5; | |
| 235 } | |
| 236 | |
| 237 // Contains information needed to begin a device enrollment. | |
| 238 message SetupEnrollmentResponse { | |
| 239 // Should return OK if the request was well formed. | |
| 240 optional string status = 1; | |
| 241 | |
| 242 // Information for each of the requested protocol <code>type</code>s. | |
| 243 repeated SetupEnrollmentInfo infos = 2; | |
| 244 | |
| 245 // Identifies what kind of resource this is. Value: the fixed string | |
| 246 // <code>"cryptauth#setupEnrollmentResponse"</code>. | |
| 247 optional string kind = 3; | |
| 248 } | |
| 249 | |
| 250 // Encapsulates a sync request from the user's device, in encrypted form. This | |
| 251 // is used to inform the server when the | |
| 252 // user's device has received a transaction, as well as to provide additional | |
|
Ilya Sherman
2014/10/06 21:15:58
nit: Odd choice of line-break.
Tim Song
2014/10/07 00:06:07
Done. The generated code used a text-width of 100
| |
| 253 // client state information useful for updating device records, debugging, UI | |
| 254 // indications, etc. | |
| 255 message SyncTxRequest { | |
| 256 // Encrypted sync request, containing state of the user's device at the time | |
| 257 // the sync request was sent, as well as indicating whether a specific | |
| 258 // transaction is desired to be | |
| 259 // sync'd, or if a list of all pending transactions should be sent back in | |
| 260 // the response. | |
| 261 optional bytes secure_sync_request = 1; | |
| 262 } | |
| 263 message SyncTxResponse { | |
| 264 // Encrypted sync response, containing any additional transaction information | |
| 265 // requested by the device for a specific transaction, or a list of all | |
| 266 // currently pending transactions if none was specified in the request. | |
| 267 optional bytes secure_sync_response = 1; | |
| 268 | |
| 269 // Identifies what kind of resource this is. Value: the fixed string | |
| 270 // <code>"cryptauth#syncTxResponse"</code>. | |
| 271 optional string kind = 2; | |
| 272 } | |
| 273 | |
| 274 // Used to enable or disable EasyUnlock features on a specified device, and also | |
| 275 // causes other devices to sync the new EasyUnlock state. | |
| 276 message ToggleEasyUnlockRequest { | |
| 277 // If true, Easyunlock will be enabled for the device with public key equal | |
|
Ilya Sherman
2014/10/06 21:15:59
nit: "Easyunlock" -> "EasyUnlock"
Tim Song
2014/10/07 00:06:07
Done.
| |
| 278 // to public_key. Otherwise, it will be disabled for that device. | |
| 279 optional bool enable = 1; | |
| 280 | |
| 281 // Encoded public key of the device to enable/disable (here you must use the | |
| 282 // same exact encoding that was sent during device enrollment). | |
| 283 optional bytes public_key = 2; | |
| 284 | |
| 285 // If true, EasyUnlock enabled state will be set to the value of "enable" for | |
| 286 // all of a | |
|
Ilya Sherman
2014/10/06 21:15:58
nit: Odd choice of line break.
Tim Song
2014/10/07 00:06:07
Done.
| |
| 287 // user's devices. This is the same as calling the toggle RPC for every | |
| 288 // device. However, this removes the need for calling GetMyDevices, so it | |
| 289 // reduces network overhead. If this field is set "public_key" must not be | |
| 290 // set. NOTE: the case enable=true is not yet supported, so this option can | |
| 291 // only disable EasyUnlock for all devices. | |
| 292 optional bool apply_to_all = 3; | |
| 293 | |
| 294 // Identifies what kind of resource this is. Value: the fixed string | |
| 295 // <code>"cryptauth#toggleEasyUnlockRequest"</code>. | |
| 296 optional string kind = 4; | |
| 297 } | |
| OLD | NEW |