Analyze EBSI Verifiable Attestation integration with AlastriaID

[alejandro-nieto-git]

Info about the AlastriaID VCs implementation in https://github.com/alastria/alastria-identity/wiki/Alastria-DID-Method-Specification#3-credentials. W3C VCs datamodel: https://www.w3.org/TR/vc-data-model/#credential-subject

DoD:

• List of things that must be adjusted in AlastriaID model to support the EBSI Verifiable Attestation

[alejandro-nieto-git]

Upon reviewing the current AlastriaID model (https://github.com/alastria/alastria-identity/wiki/Alastria-DID-Method-Specification#32-credential-payload) we can assure that the current model continues to be compliant with the W3C VC model. The following changes must be applied to the credential data of the model, the "vc" field, to be EBSI compliant:

• The first item of the "@context" MUST be https://www.w3.org/2018/credentials/v1.
• The types stated in the "type" field MUST go from more abstract to more concrete, being "VerifiableCredential" the first type for all credentials. This is not explicitly stated by EBSI but it's useful in order to know the concrete type for each credential.
• Each credential must have a unique ID in an "id" field. See the VerifiableAttestation documentation in https://github.com/alastria/alastria-identity-schemas/ for more details.
• Credentials MUST have a "validFrom" field to be able to distinguish between the issuance date and the date from wich the credential becomes valid. See the VerifiableAttestation documentation in https://github.com/alastria/alastria-identity-schemas/ for more details.
• Use of "validUntil" instead of "exp". Field "expirationDate" is allowed but won't be in future versions of the W3C VC model.
• Field "levelOfAssurance" of credentialSubject can be preserved if we use the type "AlastriaVerifiableCredential" but this will make interoperability with EBSI and other ecosystems more difficult. The utility of this field has to be taken into account when making this decision. This field is used for establishing Trust in the current AlastriaID model
• The "credentialSubject" field MUST have, atleast, an "id" field to define the DID of the subject described in the credential.
• Both the EBSI and W3C model define a "credentialStatus" field for information related to the status of the credentials, such as valid, suspended or revoked. This is not very mature for the moment and would be a different approach to credential status than the current AlastriaID model. Current options seems to cover the status established by the issuer but not from the holder one. Revocations aren't defined for the moment. It is an optional field.
• Both the EBSI and W3C model define a "credentialSchema" field to reference the schema of the credential.
• Both the EBSI and W3C model define an optional "evidence" field. See the VerifiableAttestation documentation in https://github.com/alastria/alastria-identity-schemas/ for more details.
• As of now EBSI has an optional "proof" field for credentials signed with LD-Proofs. This type of proofs are not supported and are discouraged by the new Architecture Reference Framework of the EU. Taking that into account and that the actual AlastriaID model doesn't support this field we will not support it.
• Both the EBSI and W3C model define an optional "termsOfUse" field. Since termsOfUse is closely related to the VerifiableAccreditation which is a credential specific for EBSI's Trust Model it won't be supported as of now.

In general, to be EBSI compliant the credential data must comply to EBSI's Verifiable Attestation.