Add identity keys to push

docs/specs/clients/chat/chat-authentication.md

@@ -1,6 +1,6 @@
 # Chat Authentication
 
-Given that Chat API supports multiple clients with different [Identity Keys](./chat-identity-keys.md) for the same blockchain account, we must validate different payloads:
+Given that Chat API supports multiple clients with different [Identity Keys](../../servers/keys/identity-keys.md) for the same blockchain account, we must validate different payloads:
 
 1. Invite Proposals
 2. Invite Approvals

docs/specs/clients/chat/invite-keys.md

@@ -0,0 +1,14 @@
+# Invite Keys
+
+Invite keys are used by Chat API for public blockchain account resolution.
+
+When we are registering a chat invite key we must use the following mandatory fields in the jwt:
+
+* iat - timestamp when jwt was issued 
+* exp - timestamp when jwt must expire
+* iss - public identity key in form of did:key
+* sub - public key for chat invite key
+* aud - key server url used for registering
+* pkh - corresponding blockchain account (did:pkh)
+
+Expiry will be calculated 1 hour (3600 seconds) from issued date

docs/specs/clients/push/push-authentication.md

@@ -0,0 +1,15 @@
+# Push Authentication
+
+Given that a dapp is proposing a push subscription for a blockchain account that clients don't have to authenticate in advance, the wallet needs to prove account ownership in the Push Subscription response.
+
+This is achieved using [Identity Keys](../../servers/keys/identity-keys) and did-jwt with the following claims:
+
+iat - timestamp when jwt was issued
+exp - timestamp when jwt must expire
+iss - did:key of an identity key. Enables to resolve attached blockchain account.
+ksu - key server for identity key verification
+aud - dapp's url
+sub - blockchain account that push subscription has been proposed for (did:pkh)
+
+Expiry should be calculated from the addition of the issuance date and the push request TTL (86400 seconds)
+

docs/specs/clients/push/push-proposal.md

@@ -21,13 +21,14 @@ Wallet and Dapp are required to establish pairing P before proceeding to Push pr
 Proposal protocol will be established as follows:
 
 1. Dapp sends push proposal on pairing P with public key X, relay and metadata
-2. Wallet receives push proposal with public key X on pairing P
-3. Wallet generates key pair Y
-4. Wallet derives symmetric key derived with keys X and Y
-5. Push topic is derived from sha256 hash of symmetric key 
-6. Wallet subscribes to push topic 
-7. Wallet sends proposal response on pairing P with publicKey Y 
-8. Dapp receives proposal response on pairing P
-9. Dapp derives push topic and symmetric key
-10. Dapp subscribes to push topic
-
+2. Dapp subscribes to response topic, which is the sha256 hash of public key X
+3. Wallet receives push proposal with public key X on pairing P
+4. Wallet generates key pair Y
+5. Wallet derives symmetric key with keys X and Y
+6. Push topic is derived from sha256 hash of symmetric key 
+7. Wallet subscribes to push topic 
+8. Wallet sends proposal response(type1 envelope) on response topic with subscriptionAuth
+9. Dapp receives proposal response on response topic
+10. Dapp derives symmetric key and decrypts subscriptionAuth
+11. Dapp registers address at the Cast Server
+

docs/specs/clients/push/rpc-methods.md

@@ -47,7 +47,7 @@ Used to request push subscription to a peer through topic P. Response is expecte
 ```jsonc
 // Success result
 {
-  "publicKey": string
+  "subscriptionAuth": string
 }
 
 | IRN     |          |

docs/specs/clients/push/wallet-client-api.md

@@ -8,7 +8,10 @@ abstract class WalletClient {
   public abstract init(): Promise<void>;
 
   // approve push subscription 
-  public abstract approve(params: { id: number }): Promise<boolean>;
+  public abstract approve(params: {
+        id: number 
+        onSign: (message: string) => Cacao.Signature
+    ): Promise<boolean>;
 
   // reject push subscription 
   public abstract reject(params: { id: number, reason: Reason }): Promise<boolean>;

docs/specs/servers/cast/cast-server-api.md

@@ -2,7 +2,7 @@
 
 ## Register
 
-Registers an account and push subscription symmetric key
+Registers an account and push subscription symmetric key. The `subscriptionAuth` must be attached in the request so the Cast server can verify if wallet proved ownership of an address.
 
 `POST /:project_id/register`
 
@@ -12,6 +12,7 @@ Body:
 {
     "account": string,
     "symKey": string,
+    "subscriptionAuth": string,
     "relayUrl": string
 }
 ```

docs/specs/clients/chat/chat-identity-keys.md → docs/specs/servers/keys/identity-keys.md

@@ -1,14 +1,14 @@
-# Chat Identity Keys
+# Identity Keys
 
-Identity Keys are used to verify Blockchain Account ownership and validating chat invites are legitimate.
+Identity Keys are used to verify Blockchain Account ownership and validating peer to peer requests are legitimate without requiring the wallet user to sign every message with their blockchain private key.
 
 ## Short Description
 
-These are randomly generated ed25519 key pairs that are only present one per client. The Wallet user would sign a CAIP-122 message to generate a CACAO that authorizes the client to sign messages on the behalf of the Blockchain Account
+These are randomly generated ed25519 key pairs that are only present one per client. The Wallet user signs a CAIP-122 message to generate a CACAO that authorizes the client's identity key to sign messages on the behalf of the Blockchain Account.
 
 ## Key Authorization
 
-Client will only generate a single identity key per blockchain account per client. The wallet user could use multiple blockchain accounts with a single client by authorizing one respective identity key for each. Additionally the wallet can use multiple clients with the same blockchain account by authorizing a new identity key on a new client.
+Client only generates a single identity key per blockchain account per client. The wallet user uses multiple blockchain accounts with a single client by authorizing one respective identity key for each. Additionally the wallet can use multiple clients with the same blockchain account by authorizing a new identity key on a new client.
 
 Identity Keys are ed25519 key pairs generated internally and the client will expose a CAIP-122 message which includes the public key of the Identity Key pair in the Resources in the form of a did-key.
 
@@ -82,20 +82,11 @@ Resources:
 
 ## Key Registration
 
-When two clients are using the Chat API they need to verify each others Identity Keys used in Chat invite payloads (request and response). Therefore we use the Keys Server to index these keys privately and the counter-party can validate that the key would be used for the corresponding account in the Chat identities
+When two clients are using a peer to peer API for some requests they need to verify each others Identity Keys. Therefore we use the Keys Server to index these keys privately and the counter-party can validate that the key would be used for the corresponding account in the WalletConnect identities.
 
-## Key Authentication
-
-Now that we have generated, authorized and registered Identity Keys we can use them for authentication for [different purposes](./chat-authentication.md) but also importantly we must use it to register the invite keys
-
-When we are registering a chat invite key we must use the following mandatory fields in the jwt:
-
-* iat - timestamp when jwt was issued 
-* exp - timestamp when jwt must expire
-* iss - public identity key in form of did:key
-* sub - public key for chat invite key
-* aud - key server url used for registering
-* pkh - corresponding blockchain account (did:pkh)
-
-Expiry will be calculated 1 hour (3600 seconds) from issued date
+## Authentication
 
+Now that we have generated, authorized and registered Identity Keys we can use them for authentication for different purposes:
+- [Chat Authentication](../../clients/chat/chat-authentication.md)
+- [Push Authentication](../../clients/push/push-authentication.md)
+- [Chat Invite Keys registration](../../clients/chat/invite-keys.md)

docs/specs/servers/keys/keys-server-api.md

@@ -4,7 +4,7 @@
 
 ### Register Invite Key
 
-Used to register a new invite key. `idAuth` is did jwt of claims described under section [Key Authentication](/docs/specs/clients/chat/chat-identity-keys.md)
+Used to register a new invite key. `idAuth` is did jwt of claims described under section [Key Authentication](./identity-keys.md)
 
 `POST /invite`
 
@@ -87,7 +87,7 @@ Used to get an invite key for an account
 
 ### Remove Invite Key
 
-Used to remove an invite key from the server. `idAuth` is did jwt of claims described under section [Key Authentication](/docs/specs/clients/chat/chat-identity-keys.md)
+Used to remove an invite key from the server. `idAuth` is did jwt of claims described under section [Key Authentication](./identity-keys.md)
 
 `DELETE /invite`
 
@@ -285,4 +285,4 @@ Used to remove an identity key from the server
     "name": String,
     "message": String
 }  
-```
+```