You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have to describe the ASCS verification workflow for the enrollment of members to the ASCS e.V. and ENVITED research cluster with the generalized approach of the GaiaX Trust Anker. The goal is that the ASCS becomes an official trust anker attesting the identity of participants of the ENVITED reseach cluster. Attesting basically three independent claims:
A public key hash (in this case the DID is the tezos address/pkh) belongs to a company and the information provided are sufficient and correct: Name, Address, DUNS, tax numbers .....
A company is part of the ASCS e.V. for a certain period: year 2023
A company is part of the ENVITED research cluster
(we could play with other attestations as well as e.g. consortial member of the GaiaX 4 PLC-AAD)
-> It approves the company admin or master key, the identity of the company associated with a specific DID (pkh)
-> The ASCS can now e.g. approve a login into their website, presenting community specific work flows and dedicated information
-> One of these workflows could be the attestation of employees. Now that the company is verified by the trust anker, the company itself can create a chain of trust verifying its employees and providing access levels
These claims can be the basis for application access control mechanism like "is employee with pkh X part of company Y and allowed to sign into the ENVITED marketplace"
The text was updated successfully, but these errors were encountered:
We have to describe the ASCS verification workflow for the enrollment of members to the ASCS e.V. and ENVITED research cluster with the generalized approach of the GaiaX Trust Anker. The goal is that the ASCS becomes an official trust anker attesting the identity of participants of the ENVITED reseach cluster. Attesting basically three independent claims:
-> It approves the company admin or master key, the identity of the company associated with a specific DID (pkh)
-> The ASCS can now e.g. approve a login into their website, presenting community specific work flows and dedicated information
-> One of these workflows could be the attestation of employees. Now that the company is verified by the trust anker, the company itself can create a chain of trust verifying its employees and providing access levels
These claims can be the basis for application access control mechanism like "is employee with pkh X part of company Y and allowed to sign into the ENVITED marketplace"
The text was updated successfully, but these errors were encountered: