Difference between revisions of "Verifiable Credential Generator"
Jump to navigation
Jump to search
m |
|||
(17 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
<div class="res-img"> | <div class="res-img"> | ||
− | [[File: | + | [[File:VC generator.png |Verifiable Credential Generator]] |
</div> | </div> | ||
Line 9: | Line 9: | ||
|- | |- | ||
| name | | name | ||
− | | | + | | Verifiable Credential Generator |
|- | |- | ||
| description | | description | ||
− | | | + | | Application component managing the generation, i.e., issuance of VC by the DP as issuer to the user as the holder of the newly generated (i.e., re-issued) evidence (VC). The component includes the processes of canonical evidence diploma translation into the form of a Verifiable Credential, and the digital VC signing by the issuer of the evidence. |
|- | |- | ||
| pattern(s) | | pattern(s) | ||
− | | [[ | + | | [[Verifiable Credentials Pattern|VC]] |
+ | |- | ||
+ | | application collaboration | ||
+ | |[[Authority Agent]] | ||
|- | |- | ||
− | |||
|} | |} | ||
---- | ---- | ||
Line 26: | Line 28: | ||
! Application Service !! Description !! Pattern | ! Application Service !! Description !! Pattern | ||
|- | |- | ||
− | | | + | | Convert Evidence to VC |
− | | | + | | The DP prepares the diploma evidence according to the pre-defined XML schema. The service then converts the received canonical evidence in the XML format and converts the data into the JSON-LD format of the Verifiable Credential. |
− | | [[ | + | | [[Verifiable Credentials Pattern|VC]] |
|- | |- | ||
− | | | + | |Digitally sign the VC |
− | | | + | |The diploma evidence in the JSON-LD format is submitted to the HL Aries agent deployed on the DP side to attach the ''proof'' field, i.e. to append the digital signature to the VC by using the EBSI-compliant DID. An important prerequisite for this step is that the EBSI-compliant DID is registered in the EBSI DID Registry, and that the underlying DID document is imported to the HL Aries agent upon Authority Agent startup. |
− | + | |[[Verifiable Credentials Pattern|VC]] | |
− | |||
− | |||
− | |||
− | | [[VC]] | ||
|- | |- | ||
− | |||
|} | |} | ||
Line 48: | Line 45: | ||
! Component!! Source !! UC !!Description | ! Component!! Source !! UC !!Description | ||
|- | |- | ||
− | | | + | | [[SSI Authority Agent REST API]] |
− | | | + | | DE4A |
− | | [[]] | + | | [[Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)]] |
− | | | + | | The component that exposes a set of methods as an interface to the Authority Agent's back-end functionalities. |
+ | |- | ||
+ | |- | ||
+ | |[[SSI Authority Agent Database]] | ||
+ | |[http://couchdb.apache.org/ CouchDB] | ||
+ | |[[Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)]] | ||
+ | |The component responsible for internally storing the current status of DID connections and VC/VP-related requests. | ||
|- | |- | ||
+ | |Hyperledger Aries Server | ||
+ | |[https://www.hyperledger.org/use/aries Hyperledger Aries] | ||
+ | |[[Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)]] | ||
+ | |The component deployed on the DP premises, which handles all VC (offers) generated and sent to the students. | ||
|- | |- | ||
− | | | + | |Hyperledger Aries REST API |
− | | | + | |[https://www.hyperledger.org/use/aries Hyperledger Aries] |
− | | [[]] | + | |[[Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3)]] |
− | | | + | |The component that exposes a set of methods as an interface to the HL Aries Go functionalities (DID generation, sending VC offer/VC, accepting requests, etc.). The component is used by the SSI Authority Agent REST API to implement SSI functionalities and communication between the Authority and Edge Agent. |
|- | |- | ||
|} | |} |
Latest revision as of 13:25, 11 November 2021
Item | Description |
---|---|
name | Verifiable Credential Generator |
description | Application component managing the generation, i.e., issuance of VC by the DP as issuer to the user as the holder of the newly generated (i.e., re-issued) evidence (VC). The component includes the processes of canonical evidence diploma translation into the form of a Verifiable Credential, and the digital VC signing by the issuer of the evidence. |
pattern(s) | VC |
application collaboration | Authority Agent |
Application Service | Description | Pattern |
---|---|---|
Convert Evidence to VC | The DP prepares the diploma evidence according to the pre-defined XML schema. The service then converts the received canonical evidence in the XML format and converts the data into the JSON-LD format of the Verifiable Credential. | VC |
Digitally sign the VC | The diploma evidence in the JSON-LD format is submitted to the HL Aries agent deployed on the DP side to attach the proof field, i.e. to append the digital signature to the VC by using the EBSI-compliant DID. An important prerequisite for this step is that the EBSI-compliant DID is registered in the EBSI DID Registry, and that the underlying DID document is imported to the HL Aries agent upon Authority Agent startup. | VC |
Component | Source | UC | Description |
---|---|---|---|
SSI Authority Agent REST API | DE4A | Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3) | The component that exposes a set of methods as an interface to the Authority Agent's back-end functionalities. |
SSI Authority Agent Database | CouchDB | Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3) | The component responsible for internally storing the current status of DID connections and VC/VP-related requests. |
Hyperledger Aries Server | Hyperledger Aries | Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3) | The component deployed on the DP premises, which handles all VC (offers) generated and sent to the students. |
Hyperledger Aries REST API | Hyperledger Aries | Use Case "Diploma/Certs/Studies/Professional Recognition" (SA UC3) | The component that exposes a set of methods as an interface to the HL Aries Go functionalities (DID generation, sending VC offer/VC, accepting requests, etc.). The component is used by the SSI Authority Agent REST API to implement SSI functionalities and communication between the Authority and Edge Agent. |