Issues in centralized access control
Most citizens in large centers interact with access control systems on a daily basis. Airports, buildings, meetings rooms, residences, staff areas, etc have systems to control access to different areas.
Despite the fact that current access control systems solve most problems in this field, centralized solutions have intrinsic issues related to data protection, security, privacy, scalability and offline capability.
Most of these systems rely on an architecture where a central software module stores all the data related to individuals and their permissions. Such centralised silos are already known for some disadvantages:
- GDPR: data protection regulations are present in several countries and penalities for having user's data being breached are expensive.
- Hackers: Potential point of attack for hackers or anyone with bad intentions, including the staff, considering the amount of personal data stored in a single point.
- Low offline capability: access control systems based in centralized solution aren't able to deal with cases where operation happens without access to a central module.
- Low interoperability: access rules can only be checked through the system in its proprietary implementation.
- Low privacy: user PII data can be seen by access control staff.
A decentralized solution for access control
In a decentralized solution, the access control system plays the role of a credential issuer and verfifier which won't store any personal data from users. It'll simply:
- Issue credentials containing user identification data, without storing any data internally. Such data needs to be enough to identify the user when present in the location. It can contain biometrics, user pictures, identification documents references, etc.
- Issue credentials defining the access permissions the individual has.
- Verify the credential when the user is in person in the location. This verification process can also be implemented by other parties, like partners which want to accept the same credentials.
In this solution users hold their credentials, the only place where their personal data seats. Optionaly, the data can be encrypted, or even hashed, bringing more security and privacy.
In order to implement such decentralized access control system, we could use 2 verifiable credential schemas.
Verifiable credential schemas for access control
F2F-PII: credentials containing F2F-PII (face-to-face personal identifiable information) which can be used to match its holders identity when presented to an IOT device or access control staff. Here is a generic schema which can be used to store:
- Fingerprint templates: in case an IOT device will be used to verify the holder.
- Official identification document: like national IDs, which can be presented to the access control staff to match the owner identity.
- Facial: a facial picture which will be used by the access control IOT device or staff to match the holder identity.
Access Permission: should contain:
- a link to the person who have the access
- the area she has access
- the time slot she has access
- any other rules related to the access
Issuing F2F-PII credentials
The F2F-PII is the most important VC to be issued, because it's the one which identifies the holder. It contains attributes which can be used to confirm the identity of the person holding it.
Such VCs can be used not only for this particulary use case, related to access control, but to any other use case where the VC holder needs to be identitfied in person, in a face-to-face approch.
The F2F-PII needs to be issued by a DID with recognised authority to execute KYC procedures in the ecosystem where the VC will be accepted.
The F2F-PII should be shared only with the holder identitified by it to reduce the changes of impersonation.
Issuing the Access Permission credential
The access controle credential can be issued by any DID of a party who has recognized authority to give access to some physical area. I doesn't need to be the same issuer of the F2F-PII. It enforces the decentralized aspects of the solution.
Verifying the credentials
The verifier component in the solution needs to be able to:
- check the signature of the F2F-PII VC, guaranteeing it was issued by the party with authority to execute the KYC procedures.
- match the F2F-PII VC attributes with the attributes of the person holding the VC.
- check if the holder also has an access permission matching:
- the holder identity
- the area to be accessed
- the signature from the party that can give access to the area
As examples of use we can list:
- an IOT device which reads the fingerprint of the holder and execute the verification procedure
- security staff checking the holder picture
- a security camera matching the holder face with the VC picture as an attribute and the holder sharing the VC ota.