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
Convener: Adrian Gropper and Alan Karp
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.
Q1 - What is the relationship between DIDComm and delegation?
OAuth2 AND GNAP could both be MUST
Supply chain use case - somebody signed
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