| 11 Dec 2023 |
 Ewann Gavard (Gaia-X AISBL) | Hello lenasauermann AFAIK, there's not requirement for a shape to contain the word Shape in its id. Furthermore, the shape you mention is enforced by the js-shacl engine without any inconvenience. And I personally tested with pyshacl and this internal ID without Shape causes no trouble. Maybe the problem lies in the FC project implementation you mention ? | 14:56:34 |
 lenasauermann | Hi Ewann Gavard (Gaia-X AISBL) That's true: you don't need the word Shape. But besides the SHACL-Shape, the FC also needs the ontology for a specific class and it seems like that the FC can't have the same named definition gx:DataResource in the shapes and the ontology | 15:01:42 |
| 12 Dec 2023 |
 Denis Sukhoroslov | FYI: finally, Harbor registry was configured for FC project. The latest version can be pooled as node-654e3bca7fbeeed18f81d7c7.ps-xaas.io/catalogue/fc-service-server:1.3.0-SNAPSHOT | 06:33:25 |
| Denis Sukhoroslov | * FYI: finally, Harbor registry was configured for FC project. The latest version can be pulled as node-654e3bca7fbeeed18f81d7c7.ps-xaas.io/catalogue/fc-service-server:1.3.0-SNAPSHOT | 06:48:59 |
|  Kurt Garloff changed their display name from Kurt Garloff to Kurt Garloff (SCS). | 08:37:28 |
|  yukai-sun joined the room. | 10:28:29 |
|  max-ffstudios joined the room. | 13:17:34 |
| 13 Dec 2023 |
 langec | Hi lenasauermann , sorry, didn't notice this earlier, let's clarify this on site during the workshop.
The way I understand what we specified (and how we implemented it), it is possible to upload to the Catalogue an ontology that defines a class, and a SHACL shapes graph with a NodeShape that defines how to validate instances of this class.
In what situation did this not work for you? | 12:44:07 |
| langec | To be more precise: it should not a problem to upload, as one file, to the Catalogue,
ex:MyClass a owl:Class
and to upload separately
ex:MyShape
a sh:NodeShape ;
sh:targetClass ex:MyClass .
But you must not call this shape "ex:MyClass".
Always, forget about prefixes. What's relevant for uniqueness/disambiguation is what full URIs such prefixes expand to.
| 12:46:43 |
| 14 Dec 2023 |
|  bnachit joined the room. | 10:09:14 |
| bnachit | Hello everyone,
please, i have an issue with creating a trusted connection on the OCM. I've set up the OCM and followed the steps provided on this page:
https://gitlab.eclipse.org/eclipse/xfsc/ocm/ocm-engine/-/blob/main/documentation/ocm-flow-overview.md
However, based on my understanding of the API flow mentioned in this documentation, it's indicated that two OCM instances are needed: one to create the connection invitation and the other as a provider to accept the invitation. The problem is that I'm uncertain about the architecture of these two OCM instances: will they share the same database, and how can they be differentiated?
I’ve tried to have two OCM instances with a separeted Database, but when I execute the "create invitation url" request on the provider OCM, the "state" attribute remains in "requested" state.
Below are the requests and responses I've encountered:
- Invitation creation in the connection manager of the first OCM:
• POST Request : {{conn_man_base_url_ocm}}/v1/invitation-url?alias=trust
• Response:
{
"statusCode": 200,
"message": "Connection created successfully",
"data": {
"invitationUrl": " http://gaiax.vereign.com:443/ocm/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119",
"invitation": {
"@type": " https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"connection": {
"_tags": {},
"metadata": {},
"id": "6bc4b115-bcda-4f5d-85a0-29dafa757029",
"createdAt": "2023-12-13T16:40:04.545Z",
"did": "6c9bZNKuBdevbpbjRG2HFE",
"didDoc": {
"@context": " https://w3id.org/did/v1",
"publicKey": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#1",
"controller": "6c9bZNKuBdevbpbjRG2HFE",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
}
],
"service": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#IndyAgentService",
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "6c9bZNKuBdevbpbjRG2HFE#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "6c9bZNKuBdevbpbjRG2HFE"
},
"verkey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW",
"state": "invited",
"role": "inviter",
"alias": "trust",
"invitation": {
"@type": " https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"multiUseInvitation": false
},
"invitationUrlShort": " http://connection-manager:3003/v1/url/c0497719-a2c8-410d-a2a9-fe1cfe1e6e0e"
}
}
- Accept connection on the other OCM :
• POST Request: {{conn_man_base_url_provider_ocm}}/v1/accept-connection-invitation
• Request Body :
{
"invitationUrl": http://gaiax.vereign.com:443/ocm/didcomm?d_m=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119,
"autoAcceptConnection": true
}
• Response :
{
"statusCode": 202,
"message": "Accepted Connection Request",
"data": {
"_tags": {
"state": "invited",
"role": "invitee",
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"invitationKey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
},
"metadata": {},
"id": "98863334-ff14-4da5-a4d7-ed5aff616920",
"createdAt": "2023-12-14T09:59:12.984Z",
"did": "7YzCFDEExgnav47bREhUbb",
"didDoc": {
"@context": https://w3id.org/did/v1,
"publicKey": [
{
"id": "7YzCFDEExgnav47bREhUbb#1",
"controller": "7YzCFDEExgnav47bREhUbb",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
}
],
"service": [
{
"id": "7YzCFDEExgnav47bREhUbb#IndyAgentService",
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "7YzCFDEExgnav47bREhUbb#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "7YzCFDEExgnav47bREhUbb"
},
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"theirLabel": "second-ssi-abstraction-agent",
"state": "requested",
"role": "invitee",
"alias": "connection-received",
"autoAcceptConnection": true,
"invitation": {
"@type": https://didcomm.org/connections/1.0/invitation,
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"routingKeys": []
},
"multiUseInvitation": false
}
}
Please let me know if you have any ideas on how to resolve this issue,
Best regards?
| 10:27:06 |
| bnachit | * Hello everyone,
please, i have an issue with creating a trusted connection on the OCM. I've set up the OCM and followed the steps provided on this page:
https://gitlab.eclipse.org/eclipse/xfsc/ocm/ocm-engine/-/blob/main/documentation/ocm-flow-overview.md
However, based on my understanding of the API flow mentioned in this documentation, it's indicated that two OCM instances are needed: one to create the connection invitation and the other as a provider to accept the invitation. The problem is that I'm uncertain about the architecture of these two OCM instances: will they share the same database, and how can they be differentiated?
I’ve tried to have two OCM instances with a separeted Database, but when I execute the "create invitation url" request on the provider OCM, the "state" attribute remains in "requested" state.
Below are the requests and responses I've encountered:
- Invitation creation in the connection manager of the first OCM:
• POST Request : {{conn_man_base_url_ocm}}/v1/invitation-url?alias=trust
• Response:
{
"statusCode": 200,
"message": "Connection created successfully",
"data": {
"invitationUrl": " http://gaiax.vereign.com:443/ocm/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119",
"invitation": {
"@type": " https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"connection": {
"_tags": {},
"metadata": {},
"id": "6bc4b115-bcda-4f5d-85a0-29dafa757029",
"createdAt": "2023-12-13T16:40:04.545Z",
"did": "6c9bZNKuBdevbpbjRG2HFE",
"didDoc": {
"@context": " https://w3id.org/did/v1",
"publicKey": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#1",
"controller": "6c9bZNKuBdevbpbjRG2HFE",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
}
],
"service": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#IndyAgentService",
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "6c9bZNKuBdevbpbjRG2HFE#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "6c9bZNKuBdevbpbjRG2HFE"
},
"verkey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW",
"state": "invited",
"role": "inviter",
"alias": "trust",
"invitation": {
"@type": " https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"multiUseInvitation": false
},
"invitationUrlShort": " http://connection-manager:3003/v1/url/c0497719-a2c8-410d-a2a9-fe1cfe1e6e0e"
}
}
- Accept connection on the other OCM :
• POST Request: {{conn_man_base_url_provider_ocm}}/v1/accept-connection-invitation
• Request Body :
{
"invitationUrl": http://gaiax.vereign.com:443/ocm/didcomm?d_m=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119,
"autoAcceptConnection": true
}
• Response :
{
"statusCode": 202,
"message": "Accepted Connection Request",
"data": {
"_tags": {
"state": "invited",
"role": "invitee",
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"invitationKey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
},
"metadata": {},
"id": "98863334-ff14-4da5-a4d7-ed5aff616920",
"createdAt": "2023-12-14T09:59:12.984Z",
"did": "7YzCFDEExgnav47bREhUbb",
"didDoc": {
"@context": https://w3id.org/did/v1,
"publicKey": [
{
"id": "7YzCFDEExgnav47bREhUbb#1",
"controller": "7YzCFDEExgnav47bREhUbb",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
}
],
"service": [
{
"id": "7YzCFDEExgnav47bREhUbb#IndyAgentService",
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "7YzCFDEExgnav47bREhUbb#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "7YzCFDEExgnav47bREhUbb"
},
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"theirLabel": "second-ssi-abstraction-agent",
"state": "requested",
"role": "invitee",
"alias": "connection-received",
"autoAcceptConnection": true,
"invitation": {
"@type": https://didcomm.org/connections/1.0/invitation,
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"routingKeys": []
},
"multiUseInvitation": false
}
}
Please let me know if you have any ideas on how to resolve this issue,
Best regards
| 10:28:17 |
 schulzest | The scenario what you describe is a bit different than with the normal PCM. You need in OCM 1 create a connection invite and in OCM 2 you need to accept the connection invite. There is a specical API call for it within the connection manager | 12:58:06 |
| schulzest | and yes both OCMs should have seperated databases, because in a decentralized world each and everyone is sovereign. So each (legal) entity should have it's own instance | 12:59:11 |
| schulzest | * The scenario what you describe is a bit different than with the normal PCM. You need to create in OCM 1 a connection invite and in OCM 2 you need to accept the connection invite. There is a specical API call for it within the connection manager | 12:59:42 |
| bnachit | * Hello everyone,
please, i have an issue with creating a trusted connection on the OCM. I've set up the OCM and followed the steps provided on this page:
https://gitlab.eclipse.org/eclipse/xfsc/ocm/ocm-engine/-/blob/main/documentation/ocm-flow-overview.md
However, based on my understanding of the API flow mentioned in this documentation, it's indicated that two OCM instances are needed: one to create the connection invitation and the other as a provider to accept the invitation. The problem is that I'm uncertain about the architecture of these two OCM instances: will they share the same database, and how can they be differentiated?
I’ve tried to have two OCM instances with a separeted Database, but when I execute the "create invitation url" request on the provider OCM, the "state" attribute remains in "requested" state.
Below are the requests and responses I've encountered:
- Invitation creation in the connection manager of the first OCM:
• POST Request : {{conn_man_base_url_ocm}}/v1/invitation-url?alias=trust
• Response:
{
"statusCode": 200,
"message": "Connection created successfully",
"data": {
"invitationUrl": " http://gaiax.vereign.com:443/ocm/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119",
"invitation": {
"@type": " https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"connection": {
"_tags": {},
"metadata": {},
"id": "6bc4b115-bcda-4f5d-85a0-29dafa757029",
"createdAt": "2023-12-13T16:40:04.545Z",
"did": "6c9bZNKuBdevbpbjRG2HFE",
"didDoc": {
"@context": " https://w3id.org/did/v1",
"publicKey": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#1",
"controller": "6c9bZNKuBdevbpbjRG2HFE",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
}
],
"service": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#IndyAgentService",
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "6c9bZNKuBdevbpbjRG2HFE#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "6c9bZNKuBdevbpbjRG2HFE"
},
"verkey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW",
"state": "invited",
"role": "inviter",
"alias": "trust",
"invitation": {
"@type": " https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": " http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"multiUseInvitation": false
},
"invitationUrlShort": " http://connection-manager:3003/v1/url/c0497719-a2c8-410d-a2a9-fe1cfe1e6e0e"
}
}
- Accept connection on the other OCM :
• POST Request: {{conn_man_base_url_provider_ocm}}/v1/accept-connection-invitation
• Request Body :
{
"invitationUrl": http://gaiax.vereign.com:443/ocm/didcomm?d_m=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119,
"autoAcceptConnection": true
}
• Response :
{
"statusCode": 202,
"message": "Accepted Connection Request",
"data": {
"_tags": {
"state": "invited",
"role": "invitee",
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"invitationKey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
},
"metadata": {},
"id": "98863334-ff14-4da5-a4d7-ed5aff616920",
"createdAt": "2023-12-14T09:59:12.984Z",
"did": "7YzCFDEExgnav47bREhUbb",
"didDoc": {
"@context": https://w3id.org/did/v1,
"publicKey": [
{
"id": "7YzCFDEExgnav47bREhUbb#1",
"controller": "7YzCFDEExgnav47bREhUbb",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
}
],
"service": [
{
"id": "7YzCFDEExgnav47bREhUbb#IndyAgentService",
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "7YzCFDEExgnav47bREhUbb#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "7YzCFDEExgnav47bREhUbb"
},
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"theirLabel": "second-ssi-abstraction-agent",
"state": "requested",
"role": "invitee",
"alias": "connection-received",
"autoAcceptConnection": true,
"invitation": {
"@type": https://didcomm.org/connections/1.0/invitation,
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"routingKeys": []
},
"multiUseInvitation": false
}
}
Please let me know if you have any ideas on how to resolve this issue,
Best regards
| 13:13:54 |
| bnachit | * Hello everyone,
Please, i have an issue with creating a trusted connection on the OCM. I've set up the OCM and followed the steps provided on this page:
https://gitlab.eclipse.org/eclipse/xfsc/ocm/ocm-engine/-/blob/main/documentation/ocm-flow-overview.md
However, based on my understanding of the API flow mentioned in this documentation, it's indicated that two OCM instances are needed: one to create the connection invitation and the other as a provider to accept the invitation. The problem is that I'm uncertain about the architecture of these two OCM instances: will they share the same database, and how can they be differentiated?
I’ve tried to have two OCM instances with a separeted Database, but when I execute the "create invitation url" request on the provider OCM, the "state" attribute remains in "requested" state.
Please let me know if you have any ideas on how to resolve this issue,
Best regards | 13:20:47 |
| bnachit | So, if I understand, each organization should have its own OCM? Then, yes I tried to set up two OCMs with separate databases, but in the provider OCM, when I execute the invitation acceptance request, the status remains "requested," and the alias is "connection-received" instead of "trusted." | 13:27:02 |
| schulzest | Yes, thats the basic idea:) Each organization has its own agent (ocm, acapy, afj etc. pp) which are speaking the same protocols. They just differ in scalability, features, operational concepts and security. | 15:15:06 |
| schulzest | Did you paste the link which you got from OCM1 in the second OCM? | 15:15:42 |
| bnachit | In reply to @schulzest:matrix.org
Did you paste the link which you got from OCM1 in the second OCM? Yes, I did it. If you want, below are the requests and responses I've encountered:
1- Invitation creation in the connection manager of the first OCM:
- POST Request : {{conn_man_base_url_ocm}}/v1/invitation-url?alias=trust
- Response:
{
"statusCode": 200,
"message": "Connection created successfully",
"data": {
"invitationUrl": "http://gaiax.vereign.com:443/ocm/didcomm?c_i=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119",
"invitation": {
"@type": "https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": "http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"connection": {
"_tags": {},
"metadata": {},
"id": "6bc4b115-bcda-4f5d-85a0-29dafa757029",
"createdAt": "2023-12-13T16:40:04.545Z",
"did": "6c9bZNKuBdevbpbjRG2HFE",
"didDoc": {
"@context": "https://w3id.org/did/v1",
"publicKey": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#1",
"controller": "6c9bZNKuBdevbpbjRG2HFE",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
}
],
"service": [
{
"id": "6c9bZNKuBdevbpbjRG2HFE#IndyAgentService",
"serviceEndpoint": "http://gaiax.vereign.com:443/ocm/didcomm",
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "6c9bZNKuBdevbpbjRG2HFE#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "6c9bZNKuBdevbpbjRG2HFE"
},
"verkey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW",
"state": "invited",
"role": "inviter",
"alias": "trust",
"invitation": {
"@type": "https://didcomm.org/connections/1.0/invitation",
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": "http://gaiax.vereign.com:443/ocm/didcomm",
"routingKeys": []
},
"multiUseInvitation": false
},
"invitationUrlShort": "http://connection-manager:3003/v1/url/c0497719-a2c8-410d-a2a9-fe1cfe1e6e0e"
}
}
2- Accept connection on the other OCM :
- POST Request: {{conn_man_base_url_provider_ocm}}/v1/accept-connection-invitation
- Request Body :
{
"invitationUrl": http://gaiax.vereign.com:443/ocm/didcomm?d_m=eyJAdHlwZSI6Imh0dHBzOi8vZGlkY29tbS5vcmcvY29ubmVjdGlvbnMvMS4wL2ludml0YXRpb24iLCJAaWQiOiIxNzA2YWUwYi01OWZhLTQ4ZDYtOWM4MS1iZGE3NjEyYjJhMzMiLCJsYWJlbCI6InNlY29uZC1zc2ktYWJzdHJhY3Rpb24tYWdlbnQiLCJyZWNpcGllbnRLZXlzIjpbIjQ0RGFQaW1qQjdGemttdjJQQ3JNTGVkUzdYcW1XNWNDeW4xU25FelR1UURXIl0sInNlcnZpY2VFbmRwb2ludCI6Imh0dHA6Ly9nYWlheC52ZXJlaWduLmNvbTo0NDMvb2NtL2RpZGNvbW0iLCJyb3V0aW5nS2V5cyI6W119,
"autoAcceptConnection": true
}
- Response :
{
"statusCode": 202,
"message": "Accepted Connection Request",
"data": {
"_tags": {
"state": "invited",
"role": "invitee",
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"invitationKey": "44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
},
"metadata": {},
"id": "98863334-ff14-4da5-a4d7-ed5aff616920",
"createdAt": "2023-12-14T09:59:12.984Z",
"did": "7YzCFDEExgnav47bREhUbb",
"didDoc": {
"@context": https://w3id.org/did/v1,
"publicKey": [
{
"id": "7YzCFDEExgnav47bREhUbb#1",
"controller": "7YzCFDEExgnav47bREhUbb",
"type": "Ed25519VerificationKey2018",
"publicKeyBase58": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
}
],
"service": [
{
"id": "7YzCFDEExgnav47bREhUbb#IndyAgentService",
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"type": "IndyAgent",
"priority": 0,
"recipientKeys": [
"4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx"
],
"routingKeys": []
}
],
"authentication": [
{
"publicKey": "7YzCFDEExgnav47bREhUbb#1",
"type": "Ed25519SignatureAuthentication2018"
}
],
"id": "7YzCFDEExgnav47bREhUbb"
},
"verkey": "4a77NFFJGS8P4beTvXeUzEcz7kFTjEghKW7Y2ruSAbDx",
"theirLabel": "second-ssi-abstraction-agent",
"state": "requested",
"role": "invitee",
"alias": "connection-received",
"autoAcceptConnection": true,
"invitation": {
"@type": https://didcomm.org/connections/1.0/invitation,
"@id": "1706ae0b-59fa-48d6-9c81-bda7612b2a33",
"label": "second-ssi-abstraction-agent",
"recipientKeys": [
"44DaPimjB7Fzkmv2PCrMLedS7XqmW5cCyn1SnEzTuQDW"
],
"serviceEndpoint": http://gaiax.vereign.com:443/ocm/didcomm,
"routingKeys": []
},
"multiUseInvitation": false
}
}
| 15:30:43 |
| 15 Dec 2023 |
 Tim | it does not look like you're using your own OCM, did you set it up on your own server? | 09:28:49 |
| Tim | * it does not look like you're using your own OCM, did you set it up on your own server? bnachit | 09:29:30 |
| bnachit | Tim:
Yes, I set up my own OCM by deploying the Helm Charts of the services on my server. | 10:13:28 |
| Tim | do you mind sharing the config, because looks like you're using default values | 10:47:15 |
| schulzest | ah yes, indeed. you are using default values, therefore the connections can be established successfully | 12:20:33 |
| schulzest | the conenction urls containing vereign endpoints, but they mus tpoint on your server | 12:20:54 |
|  Mitrang Lad joined the room. | 12:52:15 |
| 18 Dec 2023 |
|  Neha Puraswani joined the room. | 04:11:20 |
| schulzest | * ah yes, indeed. you are using default values, therefore the connections cant be established successfully | 08:09:46 |
