VCs presentation

[naltamura]

#integration-services hello and thank you in advance. How in SSi-bridge does the node present its own verifiable credentials?
For example, I have a master node running SSI-Bridge, an "Admin" with its own identity who is delegated to create other DIDs for other nodes within the domain.
How do the other nodes present the VC to claim that it belongs to a defined domain?

[dominic22]

I don't know if I understand you correctly but I'll try to answer your question or give you some hints where you might want to look at.

You could for instance find out the server id of the ssi-bridge using the /info endpoint returning:

{
"commitHash":"not defined",
"hostname":"localhost",
"id":"did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy",
"version":"v0.2"
}

Then you could query the identity details using the /api/v0.2/identities/<server-id> endpoint returning the credentials that can then be checked via the /api/v0.2/verification/check-credential endpoint.

{
    "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy",
    "username": "root-identity",
    "registrationDate": "2022-07-25T16:09:18+02:00",
    "claim": {
        "type": "Service",
        "name": "Integration Service"
    },
    "verifiableCredentials": [
        {
            "@context": "https://www.w3.org/2018/credentials/v1",
            "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy",
            "type": [
                "VerifiableCredential",
                "VerifiedIdentityCredential"
            ],
            "credentialSubject": {
                "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy",
                "@context": "https://schema.org/",
                "initiator": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy",
                "name": "Integration Service",
                "type": "Service"
            },
            "issuer": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy",
            "issuanceDate": "2022-07-25T14:09:49Z",
            "credentialStatus": {
                "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy#signature-bitmap-0",
                "type": "RevocationBitmap2022",
                "revocationBitmapIndex": 0
            },
            "proof": {
                "type": "JcsEd25519Signature2020",
                "verificationMethod": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy#sign-0",
                "signatureValue": "1gwMDR7vfRBuaFbU9QYWND9NLuosYtvmHEd6XuWY7uUTYfejMp7eS5FBepQE8MK9DpXYEeB2efBPDrbU5Q3MsSp"
            }
        }
    ],
    "role": "User"
}

Other nodes would need to add the id of the server to the trusted-roots in order to trust credentials signed by this identity.

[naltamura]

Ok, thanks for the reply. I want to know why, if a node has to provide its own VC in order to validate certain claims, the verification process happens inside the SSI-Bridge. I mean, node A belonging to SSI-Bridge (SSI_B1) has its own VC that claims that the node is tamper proof. The node A presents its VC to node Z. The node Z belongs to another SSI-Bridge (SSI_B2). The node SSI_B2 has among their trusted identities the identity of SSI_B1. Then Z can ask SSI_B2 to verify the VC of node A. The SSI_B2, due to the fact that trust SSI_B1, return OK, thus credentials of node A are verified. It is not clear then, why the SSI_B1 store the VC of the node A? Another point, why the node Z cannot directly verify the VC of the node A? It's only a hierarchy issue? (SSI_B1->node A) ? I'm writing a paper on an authentication model for IoT using the SSI-Bridge framework. Thanks, for the dedicated time and for the answer. Grazie, Nicola Il giorno mar 4 ott 2022 alle ore 17:23 Dominic Zettl < ***@***.***> ha scritto:

…

I don't know if I understand you correctly but I'll try answer your question or to give you some hints where you might want to look at. You could for instance find out the server id of the ssi-bridge using the /info endpoint returning: { "commitHash":"not defined", "hostname":"localhost", "id":"did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy", "version":"v0.2" } Then you could query the identity details using the /api/v0.2/identities/<server-id> endpoint which will returning the credentials which can then be checked via the /api/v0.2/verification/check-credential endpoint. { "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy", "username": "root-identity", "registrationDate": "2022-07-25T16:09:18+02:00", "claim": { "type": "Service", "name": "Integration Service" }, "verifiableCredentials": [ { ***@***.***": "https://www.w3.org/2018/credentials/v1", "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy", "type": [ "VerifiableCredential", "VerifiedIdentityCredential" ], "credentialSubject": { "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy", ***@***.***": "https://schema.org/", "initiator": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy", "name": "Integration Service", "type": "Service" }, "issuer": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy", "issuanceDate": "2022-07-25T14:09:49Z", "credentialStatus": { "id": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy#signature-bitmap-0", "type": "RevocationBitmap2022", "revocationBitmapIndex": 0 }, "proof": { "type": "JcsEd25519Signature2020", "verificationMethod": "did:iota:BPvL2gG71pcNCnqpk1uqFYRK25ELxoVKLDW18reyCnfy#sign-0", "signatureValue": "1gwMDR7vfRBuaFbU9QYWND9NLuosYtvmHEd6XuWY7uUTYfejMp7eS5FBepQE8MK9DpXYEeB2efBPDrbU5Q3MsSp" } } ], "role": "User" } Other nodes would need to add the id of the server to the trusted-roots in order to trust credentials signed by this identity. — Reply to this email directly, view it on GitHub <#713 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXFLCL4OKU5MN5NYNR7PZ5LWBRDXFANCNFSM6AAAAAAQXXTUZU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[naltamura]

What about VC are relased by trusted third entity but is revoked by the original SSi-Bridge?