docs: HIP-792 add specification and backwards compatibility sections

Signed-off-by: Brendan Graetz <bguiz@users.noreply.github.com>

HIP/hip-792.md

@@ -56,10 +56,32 @@ which is capable of handling this scenario that is presently unfulfilled by Hede
 
 <!-- The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. -->
 
+An augmentation of the existing system contract specified in HIP-632, `hederaAccountService`, with 1 new function to expand authorization checks is proposed.
+
+This will aid developers who were limited to `ECRECOVER` authorization flows, and `hederaAccountService.isAuthorized(address, messageHash, signatureBlob)` flows, who will now be able to expand authorization checks to include smart contract ID based authorization.
+
+| hash | signature | return | description |
+| --- | --- | --- | --- |
+|  | isAuthorizedCurrentTransaction() | bool | `true`` if account is authorized to carry out transaction execution on account. Accepts protobuf key signature blobs. May be used for ECDSA, EdDSA simple key flows, and complex key flows which include any of ECDSA keys, EdDSA keys, and smart contract IDs. |
+
+### `isAuthorizedCurrentTransaction()` Function Usage
+
+This function behaves identically to `isAuthorized(address, messageHash, signatureBlob)` as defined in HIP-632, with the following key differences:
+
+- It is called without specifying any parameters
+- This function extracts the values that it needs in order to validate if a transaction is authorized from the current transaction
+- Therefore it designed to be used exclusively on the current transaction, which is still in-flight (as clearly communicated by the `CurrentTransaction` suffix in the function name)
+
+No new protocol buffer schema definitions are needed as there are no parameters. Internal protocol buffers schema definitions that need to be used to process this function would be existing ones already present in Hedera's base account system, such as `Key`, `ContractID`,  `KeyList` and `ThresholdKey`. Potentially this function may also use `SignatureMap` and `SignaturePair` as defined in HIP-632, if necessary.
+
 ## Backwards compatibility
 
 <!-- All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright. -->
 
+This functionality is newly proposed and thus does not overwrite or alter existing functionality.
+
+Notably, this HIP proposes changes to neither `isAuthorized(address, messageHash, signatureBlob)` nor `isAuthorizedRaw(address, messageHash, signatureBlob)`.
+
 ## Security implications
 
 <!-- If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. -->