12A/ You MUST have a Choice of Policy Managers - Credential Issuers MUST NOT be able to impose the policy manager

You MUST have a Choice of Policy Managers - Credential Issuers MUST NOT be able to impose the policy manager

Wednesday 12A

Convener: Adrian Gropper and Alan Karp

Notes-taker(s): 

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

1 - In Verifiable Credentials (VC) protocol designs, the Issuer is typically a sovereign (state or corporation) and the Controller of a mobile or custodial wallet is sometimes an individual human, like you.

2 - You have a policy _in mind_ when you tell an Issuer what to include in a verifiable credential (VC). Let’s call this telling a permission.

3 - Your policies may change over time without the Issuer having any idea that a policy that may apply to them has changed.

4 - At any point the Issuer receives permission to issue a VC and is bound to respond to that specific instance according to _their_ policies, which are separate from yours.

5 - The point of this session is that protocols for an Issuer processing a permission for a VC issue MUST allow for you to choose your policy manager that decides on the components of the VC as encoded or linked to the permission.

6 - Giving the Issuer a role as your policy manager violates a number of human rights and security principles including the Law of Agency, Freedom of Association, Data Minimization, Separation of Concerns as well as Zero Trust Architecture.

Questions:

Q1 - What is the relationship between DIDComm and delegation?

OAuth2 AND GNAP could both be MUST

Supply chain use case - somebody signed

Audit

Q1: - DIDComm - with a notary tap uses KERI to keep the log or bust

Logging is an issue but has to be identity protected somehow (court order)

Conclusion: Another session is needed in order to discuss the application of DIDComm to Zero-Trust Architecture