# Remote Provisioning Changelog

This document provides an exact description of which changes have occurred in the
`IRemotelyProvisionedComponent` HAL interface in each Android release.

## Releases
* **Android S (12):** IRemotelyProvisionedComponent v1
* **Android T (13):** IRemotelyProvisionedComponent v2
* **Android U (14):** IRemotelyProvisionedComponent v3

## IRemotelyProvisionedComponent 1 -> 2
* DeviceInfo
  * Most entries are no longer optional.
  * `att_id_state` is now `fused`. `fused` is used to indicate if SecureBoot is enabled.
  * `version` is now `2`.
  * `board` has been removed.
  * `device` has been added.
* RpcHardwareInfo
  * `uniqueId` String added as a field in order to differentiate IRPC instances on device.

## IRemotelyProvisionedComponent 2 -> 3
* The RKP HAL now builds separately from KeyMint.
  * The HAL remains under the `android.hardware.security.keymint` package for
    compatibility with previous releases. ABI compatibility requires this.
  * Dependencies on the RKP HAL must add a dependency on
    `"android.hardware.security.rkp"` generated code (instead of
    `"android.hardward.security.keymint"`).
* ProtectedData has been removed.
* DeviceInfo
  * `version` has moved to a top-level field within the CSR generated by the HAL.
* IRemotelyProvisionedComponent
  * The need for an EEK has been removed. There is no longer an encrypted portion of the CSR.
  * Keys for new CSR format must be generated with test mode set to false, effectively removing test
    mode in the new CSR flow. Old behavior is kept unchanged for backwards compatibility.
  * The schema for the CSR itself has been significantly simplified, please see
    IRemotelyProvisionedComponent.aidl for more details. Notably,
    * the chain of signing, MACing, and encryption operations has been replaced with a single
      COSE_Sign1 object.
    * CertificateType has been added to identify the type of certificate being requested.
    * The structure has been composed to enable a clear split between what is required to validate a
      payload and the implementation-defined payload itself. This is done by creating a typed
      `AuthenticatedRequest<T>` object representing the top level data required to authenticate
      the data provided in the payload, `T`.
  * The new CSR format supports P-384 signing keys and SHA-384 hashes in the DICE chain.
* RpcHardwareInfo
  * `supportedNumKeysInCsr` added to report the maximum number of keys supported in a CSR.
  * `supportedEekCurve` is no longer used, due to the removal of the EEK from the scheme.
