agent_authorization_policy.md

Agent Authorization Policy

Version 2

Each Identity Owner creates a Policy on the ledger, identified by an address I. Each agent has an agent policy keypair that will be used with I. The policy allows a key to have some combination of four authorizations:

• 0: PROVE: agents with this authorization can create Proofs from Credentials

• 1: PROVE_GRANT: agents with this authorization can grant the PROVE authorization to other agents

• 2: PROVE_REVOKE: agents with this authorization can revoke the PROVE authorization from other agents

• 3: PROVE_ADMIN: keys with this authorization can modify the provision or revoke prove authorization policy, i.e., grant and revoke the PROVE_GRANT authorization

  • PROVE_GRANT_GRANT
  • PROVE_GRANT_REVOKE

Each authorization is either on or off. Therefore, an array of authorizations can be represented in a bitmap using the well known position for each authorization. For example in big endian, 0001 represents [PROVE], and 1000 would represent [PROVE_ADMIN].

This is a public record, but no information in this public record is ever shared with any other party. Its purpose is to allow for key management of devices in a flexible way, while allowing for entities to prove in zero knowledge that they are using an agent that is authorized by the entity. This ZKP is possible because the ledger maintains a global accumulator for all keys with the PROVE authorization, called the Prover Registry. When a key is added to a Policy, and that key is given the PROVE authorization, the ledger adds a commitment to the Prover Registry. When a key loses its PROVE authorization, the ledger removes the associated commitment from the Prover Registry.

• A can revoke A, B, and C, and where B, can only revoke B and C

• This is a deep subtopic

Setup

1. Trusted setup

   1.1. There is a global accumulator needed to store commitments to the keys with PROVE authorizations. From this accumulator, a key can prove in zero knowledge that it is authorized to prove. This requires a trusted setup.

ID Owner's First Agent

1. Agent creates policy management keypair (A_p^pk, A_p^sk) and a secret S

2. Agent creates policy address I on the ledger and adds A_p^pk as a key and ensures that key has all authorizations (111).

3. Agent adds K = Comm(S, r₀) to the PROVE authorization.

   1. What kind of accumulator to use?

4. The ledger adds commitment Comm(K, I) to the global accumulator A. The only commitments added to the global accumulator are those values with the PROVE authorization.

ID Owner's Subsequent Agents

1. One authorized agent (or multiple agents in a multisig scenario) provisions a new agent.

2. The new Agent creates policy management keypair (A_p^pk, A_p^sk) and S.

3. New agent sends A_p^pk and K= Comm(S, r0) back to the provisioning agent(s).

4. Provisioning agent(s) adds authorization for A_p^pk and K to the policy.

Lifecycle

As agents are granted PROVE authorization in address I, the ledger adds or removes the commitments to the accumulator. Agents can be added to be provisioners and revokers by admin agents. The provision or revoke policy can be changed to require more than one agent to agree on a change like 2 of 3. The ledger will enforce these rules by requiring multiple signatures complete the transaction.

Claim Lifecycle

Issuance

1. Claim Receiver sends a Claim Request, which contains a blinded link secret and blinded address I.

2. Issuer selects an index i for the claim from his non-revocation accumulator A_I.

3. Issuer generates claim C using A_I.

4. Issuer sends C and A_I to Claim Receiver.

5. Issuer adds i to his non-revocation accumulator A_I.

6. Claim Receiver provides C and A_I to Identity Owner.

7. Identity Owner gives C, and A_I to Proof Presenter.

Proof Presentation

1. Claim Presenter refreshes the revocation data from the non-revocation accumulator and Prover Registry.

2. Claim Presenter requests access from a Verifier.

3. Verifier sends a Proof Request: what must be proven and which attributes must be disclosed.

4. Claim Presenter sends disclosed claim attributes and other proofs (in zero-knowledge) and a zero-knowledge proof that

   4.1.

   4.2.

   4.3.

   4.4.

   4.5.

   4.6. is the accumulator that contains . This is shown by the next 4 statements (4.6.1 to 4.6.4)

   4.6.1. is defined for prime

   4.6.2.

   4.6.3. We say that for .

   4.6.4. It must hold that

   4.7.

   4.8. Our intention is to prove the hierarchy of commitments: is a commitment to K, which is itself a commitment to S. We want to prove the knowledge of S by putting it in another commitment .

   4.9. All values not enclosed in ()’s are assumed to be known to the verifier.

   4.10. We want to prove

   4.11. For this we need additional commitments C2,C3,C4.

   4.12.

   4.13. The proof can be prepared as concatenation of the following 4:

   4.13.1. NIZK{ (,): ( in ) && = Comm(, ) } = Comm_Acc proof

   4.13.2. NIZK{ (K,I,): Credential(I) && =Comm(K,I,) } = Claim+commitment proof

   4.13.3. NIZK{ (K,I,,): = Comm(K,I,) && = Comm(Comm(K,I),) } = D_Comm proof

   4.13.4. NIZK{ (S,,,,I): = Comm(S,) && = Comm(Comm(S,),I,)} = D_Comm proof

   These 4 proofs can be united into a single one with some reduction in size.

   4.14. Claim index i has not been revoked yet.

5. Claim Presenter generates

6. Claim Presenter computes

   6.1.

   6.2.

   6.3.

   6.4.

   6.5.

7. Claim Presenter sends to Verifier

8. Verifier validates the proof

   8.1. Computes and

   8.2. Verifies that

"I am a valid claim presenter"<=

<="I am part of the claim policy"<=

<="My public key is part of the claim policy"<=

<="I know the private key of the public key of the claim policy"<=

<="I know a private key and a public key which are part of the policy that is part of the claim."<=

<="I know S which is private key of a public key which is part of the policy that is mentioned in the claim”<=

<="I know K and S s.t. K is a commitment to S, and K is part of the policy that is mentioned in the claim”<=

<="I know K and S s.t. K is a commitment to S, and K is part of policy I, and I is the policy in the claim”

<="I know K and S s.t. K is a commitment to S, and (K,I) belong to the key-policy accumulator in the claim, and I is the policy in the claim”<=

<="Here is C₁ which is a commitment to K which is a commitment to S, s.t. (K,I) belong to the key-policy accumulator, and I is the policy in the claim”

Potential attacks

1. Inspecting the ledger reveals all of the agents that are associated with an entity. Hence even if A_p^pk is revealed for one agent, agent is correlated to the entity, all agents of that entity are correlated.

   1. The security is provided by the fact that A_p^pk cannot be derived from or correlated to the proof.

2. An agency that is malicious or compromised (all storage is encrypted). Kinds of compromises:

   2. Agency router logs are leaked, but the router is still in control of agency.

   3. Adversary is able to get into Agency machines and eavesdrop on all events (server logs, read disk files, etc) but still not manipulate agency machines.

   4. Active attack (partial control): The adversary controls and is able to manipulate some part of the agency.

3. It will become obvious to third parties how secure a given address (person or organization) is. Does this encourage an attacker?

4. Correlation by network inspection (source/destination IP address, inference of packet timing and size)

   5. An agency router can act as a privacy-enhancing proxy.

      1. Reason 1, by going through a proxy, the recipient would see the proxy's IP address, not the sender's IP address. Because many are using the same proxy, this masks the sender somewhat.

      2. Reason 2, an attacker could correlate based on the timing of messages or the size of messages sent through a router. A Router could hold messages for a random period of time before forwarding, and add random number of bytes of garbage to a message to thwart these types of inference attacks.

      3. Note: this could motivate an attack on a major agency for the purposes of eavesdropping.

   6. With this solution, isn't It now *more *imperative that we employ a mix network? Or did we have the same risk with correlation of IP addresses?

Version 1

TO ADD: agents can be linkable within the same relationship (DID-DID), but not across relationships.

UPDATE: Simplification with scheme

0. Introduction

This protocol supports:

• Unique Identity Owner;

• Multiple Indistinguishable Claim Receivers;

• Multiple Distinguishable Claim Presenters (Agents);

• Unique Updateable Agent Revoker;

• Unique Non-updateable Provisioner.

1. Table of assets and roles

Asset\Role	Identity Owner	Provisioner	Claim Receiver	Claim Presenter	Claim Revoker	Agent Revoker	Verifier	Claim Issuer
Agent key aag				O
Agent revocation key aar						O
Agent ID Vag		KM		O		KM
Agent Revoker ID Var		K				O
Provisioning key apr		O
Provisioning ID Vpr		O	K	K
Agent certificate Sa		KM		O
Link secret als	O		K	K
Claim revocation key acr					O
Claim revocation ID Vcr			K	K	K
Owner defined attributes AO	O		K	K			K
Issuer defined attributes AI			K	K			K	O

Legend

O: owns

K: knows

KM: knows multiple values

2. Construction

• (a_ag, V_ag) - private-public signature keypair, unique for agent.

• (a_ar,V_ar) - private-public signature keypair;

• (a_pr,V_pr) - private-public signature keypair;

• S_a = Sig_{a_pr}(V_ar,V_ag)

• (a_cr,V_cr) - private-public signature keypair;

• Claim attributes signed by Issuer: V_pr,a_ls, identity attributes

3. Use cases

3.1. Setup

3.1.1 Identity Owner

1. Identity Owner generates link secret als as a random value

2. Identity Owner defines owner-defined attributes A_O;

3. Identity Owner selects an agent accumulator: his own one or a global one.

3.1.2 Provisioner

1. Provisioner generates provisioning key a_pr;

2. Provisioner computes provisioning ID V_pr;

3. Provisioner tells V_pr to Identity Owner.

3.1.3 Claim Receiver

1. Claim Receiver gets V_pr from Identity Owner.

3.1.4 Agent Revoker

1. Agent Revoker generates agent revocation key aar and agent revocation ID V_ar.

2. Agent Revoker submits V_ar to Provisioner.

3.1.5 Claim Presenter

1. Claim Presenter generates agent key aag and agent ID V_ag.

2. Claim Presenter submits V_ag to Provisioner.

3. Provisioner creates agent certificate S_a for Claim Presenter.

4. Provisioner adds S_a to the agent accumulator and sends S_a to Agent Revoker.

5. Claim Presenter stores S_a.

3.2 Claim Lifecycle

3.2.1 Issuance

8. Claim Receiver gets A_O, als from Identity Owner;

9. Claim Receiver contacts the Issuer and submits A_O, a_ls, and V_pr in the blinded form.

10. Issuer selects an index i for the claim and adds it to A_I.

11. Issuer generates claim C using A_I.

12. Issuer sends C and A_I to Claim Receiver.

13. Issues adds i to his non-revocation accumulator.

14. Claim Receiver provides C and A_I to Identity Owner.

15. Identity Owner gives C, A_O, a_ls,A_I, and V_pr to Claim Presenter.

3.2.2 Presentation

9. Claim Presenter refreshes the revocation data from the non-revocation accumulator and agent accumulator.

10. Claim Presenter contacts Verifier.

11. Verifier provides a presentation policy: what attributes must be disclosed.

12. Claim Presenter presents claim attributes (in zero-knowledge) and a zero-knowledge proof that

    23. He knows Vpr contained in the claim;

    24. He knows (V_ar,V_ag),S_a, where S_a is a signature of (V_ar,V_ag) on V_pr;

    25. He knows private key corresponding to V_ag;

    26. Vag has not been revoked yet.

    27. Claim index i has not been revoked yet.

13. Verifier checks the proof.

3.2.3 Revocation

1. Issuer selects the index i to revoke.

2. Issuer removes i from the non-revocation accumulator

3.3 Agent Revocation

1. Agent Revoker selects the agent he revokes and retrieves his agent ID Vag and certificate S_a.

2. Agent Revoker approaches the agent accumulator and provides S_a and a zero knowledge proof that

   1. S_a is a signature on some key on some (V_ar,V_ag).

   2. He knows the private key from V_ar.

3.4 Agent Revoker Rotation

1. Generate new Agent Revoker ID.

2. Issue new agent certificates using the new Agent Revoker ID.

3. Replace the old agent certificates with the old ones.

4. Revoke the old agent certificates

4. Simplification

The process can be simplified if we assume that the Identity Owner has a software/hardware vault, where he keeps all most valuable secrets and runs protected code. Then the Provisioner code may run there, and needs only occasional interaction with the outer world to publish his ID, provision new agents, and revoke them.