Attribute-based Access Control on Solid Pods
using Privacy-friendly Credentials

Our demo showcases how a user is granted access to resources stored on a Solid Pod, i. e., a web server that adheres to the Solid Protocol,
using Web-based Verifiable Credentials.

Authors: Christoph Braun from AIFB @ Karlsruhe Institute of Technology (KIT), Germany

Check out the live Demo » Get the code »

Abstract

Our demo showcases how a user is granted access to resources stored on a Solid Pod, i. e., a web server that adheres to the Solid Protocol, using Web-based Verifiable Credentials. To protect the privacy of the user, we rely on the BBS+ signatures scheme allowing for selective disclosure of only those attributes necessary. We present a PWA where a user can (a) request a Verifiable Credential from another user, (b) store it on their own Solid Pod, and (c) use it to gain access to a resource on a third user’s Solid Pod.

Illustrating Example

Consider the setting depicted in Figure 1: Charlie is organising a public workshop with many attendees. Alice is one of the demo presenters at the workshop. Whoever attended the demo may access a digital badge, provided by Charlie. As the attendees can choose on-site which demo to attend, Charlie cannot know beforehand who attended, e. g., Alice’s demo. Instead, Alice issues a corresponding VC to her attendees, one of which is Bob. Bob can then present this VC to Charlie’s Pod. However, the VC contains the time when the attendee visited Alice’s demo, but Charlie only requires to know if (and not when) Alice’s demo was attended. Bob can selectively disclose only the necessary attributes and is granted access to the digital badge.




Figure 1: A high-level overview of the demo abstracting away any app to purely illustrate the provided functionality.
(Comic icons from flaticon.com; created by Freepik, except for the cloud server which was created by vectorsmarket15.)


Walkthrough

We have a live demo, where you can play around! You take the role of Bob from Figure 1! For example, try the following:

  1. Log in with your Solid WebID (using the button in the top right corner).
    Don't have a Solid WebID and associated Solid Pod yet? Take a look here.
  2. Click the GET button to try to access the demo resource. You will get a 403 - User Unauthorized.
  3. Check your wallet by clicking on the speed dial (the big green button at the bottom center) and then by clicking on the appearing wallet symbol.
  4. Request a new credential with which you can unlock the demo resource. Click on the speed dial, and then on the appearing plus symbol.
  5. Check out your inbox by clicking on the profile picture with the green badge displaying the number of resources currently available in your inbox.
  6. Inspect your messages. There is a credential in the inbox waiting to be saved to your wallet. Click on the save button (the floppy disk symbol).
  7. Unlock the demo resource. Using the speed dial navigate back to the screen with the GET button.
    Click on the speed dial and then click on the appearing lock symbol.
    A dialog prompts you to select a credential and subsequently to select the attributes to disclose.
    Another dialog will open and asks you to select a key to sign the credential.
    By providing a name and clicking on the plus icon, you can create a new keypair.
    After you selected a key, the derived credential is automatically signed for you and sent to the agent controlling the demo resource.
  8. OPTIONAL: Do not disclose visitedPFCdemo. Your access request will be rejected.
    When you disclose this attribute, the access request will succeed.
  9. Check out your inbox. There is a message which informs you that you have been granted access to the demo resource. (Assuming you disclosed said attribute.)
  10. Check out the demo resource. Navigate back and hit GET again. You will see the content displayed in the text field.

    11. Congratulations on completing this demo!


Figure 2: Preview screenshots of the demo app.

Data Modeling

Our demo relies on the Solid Protocol [7]: We use WebIDs [8], i. e., a URI that identifies a user, Linked Data Notifications (LDNs) [9] for communication between users, and Solid Pods for storing personal information, credentials and so on. Following the W3C recommendation, we use the Verifiable Credential data model [6] with the BBS+ signatures scheme [10] which allows for the desired selective disclosure of attributes.

An example (in JSON-LD format) for the Verifiable Credential used in the demo is illustrated below.
Notice that there are two proofs:

  1. One of the derived credential with a derived signature of the issuer (https://uvdsl.solid.aifb.kit.edu/profile/card#me)
  2. One of the derived credential with the signature of the holder (https://uvdsl.solidweb.org/profile/card#me)
This way, the validity of the credential can be verified, and at the same time, the holder can be authenticated. 

{      
    "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/citizenship/v1",
    "https://w3id.org/security/bbs/v1",
    {
      "CredentialPIDKG": {
        "@id": "http://example.org/vocab#CredentialPIDKG",
        "@type": "@id"
      },
      "AttendeePIDKG": {
        "@id": "http://example.org/vocab#AttendeePIDKG",
        "@type": "@id"
      },
      "visitedPFCdemo": {
        "@id": "http://example.org/vocab#visitedPFCdemo"
      }
    }
    ],
    "id": "https://example.org/cred#1656354322824",
    "type": [
      "CredentialPIDKG",
      "VerifiableCredential"
    ],
    "description": "A credential issued by Christoph (uvdsl) to a person attending the demo booth.",
    "name": "PIDKG Demo Credential",
    "credentialSubject": {
      "id": "https://uvdsl.solidweb.org/profile/card#me",
      "type": [
        "AttendeePIDKG",
        "Person"
      ],
      "visitedPFCdemo": "true"
    },
    "issuanceDate": "2022-06-13",
    "issuer": "https://uvdsl.solid.aifb.kit.edu/profile/card#me",
    "proof": [
      {
        "type": "BbsBlsSignatureProof2020",
        "created": "2022-06-27T18:25:25Z",
        "nonce": "250lBxAuHRuEmM7RfJLOibQk0yEY1mbAopzS5CcSiDycgfSbzxt3522uZpKCDhhJoEw=",
        "proofPurpose": "assertionMethod",
        "proofValue": "AA9v/7a3AKWM4kTmW1W2NPpzpQwmdvhqmaU2rDG5hpLlUDfUFPmkrp88yzVNfoqa5Pqg1bRMyJWEItNm5NW2dhZKwX37qDETUVsoLD7RbQATB7FNEzem3Hgscqdur93c9sspEoapLLGMZT68VPP/5rCxxoVJPoOx2oEqvSbacY7PUdVn6b4Je8IgawRthTgx5znm6AAAAHSKpRPlE/g/T77mtkzxO1g/cqn5cTgAD1h70Fplw03iOm8lsT/giFPV2i+Shln63PIAAAACGl7I2uzoG+ffLDApCJm7Q0jp1z3pBGF/Okd0dF0rge8AU6TAumEGOYjP6MxUEzDi4tgbyam8D8AHV+g6TEtGIpLMYh8PlK99gTPoo84vom9aZH2KgpqJtg8S8xRXAQnm6J/WwdU91QDnUmcM8/LgXwAAAANG2l5umdBo2vOlo1CTbOgeb79ZZ1is2MDrxX9okuRZUg/+lVXWUf/jCQIZhVGrGe4S9oBV3WYu59dTN2w4igtdUe28D9MAM5ghABkcJehaC7juJ9t4/SX/M6/h+y9Of7o=",
        "verificationMethod": "https://uvdsl.solid.aifb.kit.edu/public/keys/pidkg#key"
      },
      {
        "type": "BbsBlsSignature2020",
        "created": "2022-06-27T18:39:59Z",
        "proofPurpose": "assertionMethod",
        "proofValue": "lAwnclhBfIlg+14kK84l36obpKIn1BeRjeVGKREAd2M0qme0gGfPpxEM89Gq1Na0JCnEtTwjwrWwRlJQ9cn1MplfQeDKRjkzupe69eHIBQ8aIfajglvyl2DS/+Fh4QWzH3ttqMfqf0bk76+VhREOSw==",
        "verificationMethod": "https://uvdsl.solidweb.org/public/keys/7525b880-f647-11ec-9704-b717df451657.jsonld#key"
      }
    ]
}

Not only that: Check out the public key of the holder at https://uvdsl.solidweb.org/public/keys/7525b880-f647-11ec-9704-b717df451657.jsonld#key : 

{   
    "@context":[
        "https://w3id.org/security/v2",
        {"label":"http://www.w3.org/2000/01/rdf-schema#label"}
    ],
    "id":"https://uvdsl.solidweb.org/public/keys/7525b880-f647-11ec-9704-b717df451657.jsonld#key",
    "label":"play",
    "controller":"https://uvdsl.solidweb.org/profile/card#me",
    "publicKeyBase58":"24TfzuTmvydD7BuhaWa8e5tEVy3FiVZfZNZit5EGR6aV5oFt6bXcedRYrnv7KzSH2t2wZbCFddXAAHA5aX5AJL1kBNisvDuJnuBUZsHCuu62KVsgQrPdERBgjHQVNZinjX7i",
    "proof":{
        "type":"sec:BbsBlsSignature2020",
        "created":"2022-06-27T18:32:11Z",
        "proofPurpose":"assertionMethod",
        "proofValue":"lePYwxorprb+nTpMAf/ocisT4dcbEUBqPnFmJ8g4DBvFjlsbNwbYe2QJe2KzuYKTZeNN85dpr/yZnFTksHubglYKzVtl25OSC0GyZq4wVBRyyJl/ppoFQqhSwQd4DC2n+FuSucB/nf6K3RQhkU8S1Q==",
        "verificationMethod":"https://uvdsl.solidweb.org/public/keys/7525b880-f647-11ec-9704-b717df451657.jsonld#key"
    }
}

The public key is also signed by the holder with its own corresponding private key! This means that the holder must be in possession of the private key.

So when you receive a message signed by this public key, you can check the signature of this public key, and thereby authenticate the holder. No other agent could have sent you this message.

An example (in JSON-LD format) for an access request via a Linked Data Notification (LDN) [9] in the demo is illustrated below: 

{
    "@context":[
        "https://schema.org/version/latest/schemaorg-current-https.jsonld",
        "https://www.w3.org/2018/credentials/v1",
        "https://w3id.org/security/bbs/v1",
        {
            "acl:Authorization":"http://www.w3.org/ns/auth/acl#Authorization",
            "acl:agent":"http://www.w3.org/ns/auth/acl#agent",
            "acl:accessTo":"http://www.w3.org/ns/auth/acl#accessTo",
            "acl:mode":"http://www.w3.org/ns/auth/acl#mode",
            "acl:Read":"http://www.w3.org/ns/auth/acl#Read",
        }
    ],
    "type": "AskAction",
    "agent": "https://bob.solid.aifb.kit.edu/profile/card#me",
    "recipient": "https://charlie.solid.aifb.kit.edu/profile/card#me",
    "about": {
      "type": "acl:Authorization",
      "acl:agent": "https://bob.solid.aifb.kit.edu/profile/card#me",
      "acl:accessTo": "https://charlie.solid.aifb.kit.edu/conf/pidkg/demo",
      "acl:mode": "acl:Read",
    },
    "vc": { "@context":[ "https://www.w3.org/2018/credentials/v1", ... 
}

This is only a proof-of-concept. We envision transmitting the credential directly in the HTTP GET request, e.g., in a header.

Discussion of System Architecture

With the current architecture, we aim to provide more of a proof-of-concept for attribute-based access control with focus on data minimisation rather than a production-ready implementation: For example, access to a resource is granted asynchronously to the actual resource access. We envision that the outlined verification procedure is directly tied to HTTP requests. Instead of LDNs, the required information is exchanged within the HTTP requests and responses, e. g., using headers. This way, any relevant information regarding access control can directly be exchanged between the agents. Moreover, any inconsistency regarding the user’s authorization, e. g. in case of expiring or revoked credentials, are avoided Modelling access control rules to express, e. g., which attributes of a credential are required, is left for future research, as even ACPs [5] are still evolving.

An additional issue poses the secure storage of credentials on the Solid Pod. Typically, credentials are stored on the user’s end-device outside of the control of others. Providing Solid- based cloud credentials should be similarly secure and reliable, especially when considering that most users do not host the Solid Pod themselves but rely on third party Pod providers. Corresponding trade-offs need to be considered when deciding where to store the credentials.

To improve users’ privacy beyond selective disclosure, we also look at providing anonymous credentials [15]. Currently, the WebID of the holder needs to be disclosed for authentication. With anonymous credentials, the holder can prove the attribute required for resource access without revealing his identity. Enabling additional Zero-Knowledge Proofs, e. g., range proofs or set membership proofs, for Linked Data-based credentials poses also promising future research

Discussion of Related Work

We briefly survey related work in the realm of Verifiable Credentials (VCs) and Solid. An early description about the Solid project is provided in [11]. The Verifiable Credential data model [6] is a recent W3C recommendation for sharing verifiable claims. Mentioned there as a valid signature scheme, the draft specification of Linked Data Proofs has been renamed Data Integrity3, now noting the usage of Linked Data only as an optional feature.

Combining Solid and VCs, Ezike presented a system for issuance, handling and revocation of VCs [12]. Ezike envisioned an ecosystem of applications where access to restricted services and resources would be granted relying on such VCs. As credential signatures, however, only simple JSON-LD signatures are used. This poses a privacy issue regarding data minimisation when more information than necessary would be disclosed with a presented credential. In our work, we take a step towards the declared vision by showcasing how a user can be authenticated and subsequently granted access to resources under access control. At the same time, we address data minimisation by supporting selective disclosure via BBS+ signatures [10].

The BBS+ signature scheme [10] is based on the strong Diffie-Hellman assumption, as first presented by Boneh et al. in [13]. Similar in goal but based on a different hardness assumption, Camenisch and Lysyanskaya presented CL signatures [14], which are typically used in “anonymous credentials” to achieve anonymity of the holder [15]. Camenisch and Lysyanskaya also describe an approach to anonymous credentials using BBS where modifications are necessary [15], which are provided by BBS+ [16]. Thus, BBS+ is also suitable to create anonymous credentials which we have not yet implement in our system.

Access control in Solid is implemented using Access Control Lists (ACL) [17]. With ACLs, different modes of access to resources can be granted for specific agents or agent groups. A new alternative is introduced with Access Control Policies (ACP) [5], whose specification is still under development. The current ACP darft specification mentions VCs in the context of access requests. Our prototype showcases how such VCs can be used for access control on Solid Pods.

SSIBAC [18] was presented as a system for access control based on Self-Sovereign Identities [1]. The system fundamentally relies on distributed ledger technology for managing identifiers and associated cryptographic keys to provide attribute-based access control on resources in the information system. Their credentials specifically rely on the Hyperledger Indy4 framework. In contrast, our system relies on Web standards and the Solid Protocol.

References

Code

The code of our demo PWA is available on GitHub.
The code of our proof-of-concept server module is available on GitHub.

Authors