Draft: EBSISD-2258

• Add EA schemas - work/employee credentials

requested review from @taimema

assigned to @horvaal

added 1 commit

• 101917cc - employee-badge: adding credentialStatus to allow revocation

Compare with previous version

added 2 commits

• c518b45e - attestation-of-employment: turning currentAddress into object for computer processing
• fbbf6b1b - certificate-of-work: adding currentAddress as an object for computer processing

Compare with previous version

this is a bit broken

might be easier to migrate into VC 2.0 baseline

running npm run test will report couple errors.

Test Suites: 2 failed, 2 total
Tests:       7 failed, 65 passed, 72 total
Snapshots:   0 total
Time:        1.443 s

added 1 commit

• 0a23ab3e - fixing position of required for currentAddress sub-property

Compare with previous version

added 3 commits

• 3d02137d - minor update
• 5790efb5 - cert of work new version
• 9a355d0f - run prettier

Compare with previous version

@n003gcp8 please review the new proposed schema. See also the README.md

If the design and structure are good, we'll apply the same to other 2 schema.

@horvaal I don't think using VerifiableId2023 for the business company will meet the legal requirements. For example, the corporateAddress is required by law in a Certificate of Work, while the VAT Number (even if not required in VerifiableId2023) is involving out-of-context information.

I would recommend a flat structure instead of a composition of schemas to keep things simple and easier to match with the legal requirements and standard practices.

Hi.

I understand. However, we'd like to re-use the existing claims to the largest possible extent to not have different claim names for the same content.

Verifiable id contains the legal address. Is it the same as corporate address? For the work creds we make required only claims that you tell us are required, we'll remove everything else. I'd like to see whether we can re-use the existing data model as per eIDAS (v1).

We can make the structure flat.

@horvaal I understand the intent of re-usability, but I don't know if the subject of corporate identity is mature enough (and harmonized enough accross the EU) to have a workable model at the moment.

What is the eIDAS (v1) json schema for corporation? Is that VerifiableId2023?

The thing is that VerifiableId2023 seems like a tax oriented schema.

For HR (at least in France which is the case I know the best), corporations may have multiple sites. The identity, for a certificate of work, is the identity of the site. Reality may even become rapidly more complex.

A flat structure is the easiest to map data, to understand what to export from legacy database and to operate the flows. Most of the legacy systems are used to export HR data to a denormalized structure (e.g. to produce PDFs). Adoption will be easier if we keep credentials the same way for the moment.

eidas v1 Legal Entity verifiable id claims are the one in the VerifiableId2023. We added domain name, but we can add additional claims.

See: https://ec.europa.eu/digital-building-blocks/wikis/display/TDD/2.1+-+Identity+and+Record+Matching+-+Q4+2022#id-2.1IdentityandRecordMatchingQ42022-2.5eIDASattributesforLegalPersons

and: https://semiceu.github.io/Core-Business-Vocabulary/releases/2.1.0/

Can you list the claims that should be there for the issuer and we check what claims already exist and what additional claims we need to add.

We can change the structure to flat, we can also define required/optional claims as it suits the use case.

OK, I definitely see that the eidas v1 is a Tax oriented identity.

Taking the French case, we have the often the problem of mapping tax identity (VAT number), with employment identity (SIREN for company, SIRET for site). While mapping is straightforward for small businesses, it is not for larger companies.

Again, I'm not sure that the subject is mature enough to enrich the basic data model. It is probably better to keep it as it is for tax purposes and to see when/if it makes sense to create another identity for other domains (like HR, supply chains,...)

We can also simplify the model for the piloting purposes. Can you suggest what would be the minimal model for LE identification for the pilot?

This time, it is the subject of digital credentials that is not mature enough to make wise choices.

A certificate of work is actually a paper, signed by a "representative" of the company, to certify that a leaving employee has worked for a certain period and can claim some rights to different entities (like unemployment agencies). Things are currently processed very manually and the PDF is the closest form of a digital representation of this certificate of work.

The point is that from a legal point of view, the physical signature of the representative may have more legal importance in case of disputes than the correct address of the company. Which means that it is not clear that validating digitally the identity of the company has any real implications.

Again, we should keep things simple and try to adhere to the existing processes. It is better to improve incrementally from the usage of PDFs and try to avoid complicating adoption with uncertain modifications.

I agree.

Issuer information is for display purposes. Liability is on the person issuing the document on behalf of the org. (legally recognised signatures can be created by signing the VC with a qualified digital certificate).

What if we set the following for the issuer:

• did
• legalName
• domainName
• contact point (e.g., email)

Accountable person

• name
• surname

And keep the credentialSubject as is for the purpose of the pilot.

WDYT?

I'm not really convinced.

I believe we would be mixing things before having a clear understanding of the "root" entities used for composition:

• for now, the issuer is anchored in the EBSI Verifiable Attestation and this is probably because we don't have a naming service yet that we try to add the element you're describing
• a certificate of work is currently only displayed information and this is the physical signature that provides certification of their correctness.

People that use these certificates, actually transform this incoming information into their system, and it is their validation that provides the legitimicy of the claims.

Again, I believe we miss jurisprudence to be comfortable in design choices. I would feel more at rest if we duplicate what is existing: someone signs a flat structure of data and is considered responsible if one of the elements is wrong (like a mis-spelled corporate name), this does not invalidate the certificate and the rights that the holder can claim.

We should go back to the value we can add to a PDF: a Verifiable Credential is providing a more flexible and reliable way to transmit the information between the issuer (the business company) and the verifier (the unemployment agency). The concepts of LE Issuer and Accountable Person is adding legal implications that we can not really measure with no easy to explain benefits to the current verifiers.

What would be the actual business benefits of having issuer details and accountable person?

Issuer details and accountable person information were in the first proposal, however they were included in the credential subject.

We can remove the issuer info and just leave the "id" property which is the DID of the issuer. Would that work?

In the first data model, the following claims were in the credential subject:

{
  "placeOfIssuance": {
    "description": "Defines the location where the ceritificate of work of the credential subject has been issued",
    "type": "string"
  },
  "dateOfIssuance": {
    "description": "Defines the date when the certificate of work of the credential subject has been issued",
    "type": "string",
    "format": "date"
  },
  "corporateName": {
    "description": "Defines the corporate name of the company that issued the certificate of work of the credential subject",
    "type": "string"
  },
  "businessName": {
    "description": "Defines the business name of the company that issued the certificate of work of the credential subject",
    "type": "string"
  },
  "corporateAddress": {
    "description": "Defines the address of the company that issued the certificate of work of the credential subject",
    "type": "string"
  },
  "corporateRepresentative": {
    "description": "Defines the representative of the company that issued the certificate of work of the credential subject",
    "type": "string"
  }
}```

So I tried to move them to the issuer property and find established vocabulary for the respective claims. We can also remove them

My understanding is that you proposed to restructure the information concerning the company (which were marked as required) and put them in the issuer property refering to another schema. You also proposed to restructure the part concerning the corporate representative in an accountablePerson property (with a corresponding core schema).

It should be noted that all the fields in the initial flat structure that were marked as "required" are actually required by law (or by established practice).

Why do we have to restructure the initial flat list? What are the legal implications? What are the business benefits?

We should keep things simple to ease adoption. When people use the schemas (if we manage to convince them to), they will be the best ones to tell us what we should modify.

Issuer object is intended to carry the issuer-related information. That's the only reason.

This will enable us to construct more coherent schemas across different use cases. If it is possible, I'd move the issuer-related claims to the issuer object and mark them required (as you specified).

This should simplify the adoption since the same issuer-related claims can then be re-used by other use cases.

Alen, I mentioned above that the issuer is the intrinsic concept within the Verifiable Attestation schema. If you want to insert information on the issuer that can be re-used accross schema, this is the place where it should go.

Simplicity simplifies adoption. Re-usability makes adoption harder and maintenance easier. We have some legs before having maintenance problems.

Your recommendation is to keep the organisation information in the credentialSubject?

Yes, my recommendation is to have everything that is displayed in a "work certificate" in the credentialSubject.

Today, when companies offer the ability to download a work certificate from their web site, they make a request to their ERP (or rest request to their HR or PaySystem solution provider) and put the record in a template that generates a PDF.

My recommendation is to let them do a simple mapping of the same record in the credentialSubject fields. It will simplify migration and avoid possible regressions (with possible legal implications).

We're trying to follow the design of VCs and the principles introduced there. Although the flat structure appears appealing, it is recommended to split the information by context.

The value of the credentialSubject property is defined as a set of objects that MUST contain one or more claims that are each related to a subject of the verifiable credential.

There are 2 options: a) as proposed, issuer information is moved to the issuer object (see also example https://w3c.github.io/vc-data-model/#example-usage-of-issuer-expanded-property) b) have 2 credential subject objects, one for the employee and one for the employer

Signature-related information (location, time) will be in the signature header - JOSE header as defined by JAdES; properties: sigPl, sigT, respectively.

Option A
{
  alg: ...,
  sigT: <claimed signature time>,
  sigPl: {schema of: https://schema.org/PostalAddress},
}.{
  <VC claims>,
  issuer: {
    id: did:ebsi:..,
    legalName: Company ABC
  },
  credentialSubject: {
    id: did:key:...
    firstName: ...,
    ...
  },
  other VC claims
}

Option B
{
  alg: ...,
  sigT: <claimed signature time>,
  sigPl: {schema of: https://schema.org/PostalAddress},
}.{
  <VC claims>,
  issuer: id: did:ebsi:123,
  credentialSubject: [{
    id: did:key:...
    firstName: ...,
    ...
  },
  {
    id: did:ebsi:123,
    legalName: ...,
    ...

  }
  ],
  other VC claims
}

Both options are valid, A is preferable since all the issuer-related information is in the same element.

Rendering VCs is something that we still need to address.

I agree on the option A, where issuer property contains all issuer's self-attested properties.

Multiple credentialSubject entries may be used to combine different, but related subjects or topics. If the credentialSubject content have composite relation, then it makes sense to use multiple entries.

If issuer happens to be 3rd party, then the employee and employer should be different entries in credentialSubject

mentioned in merge request !3 (merged)