Connector Registration | Tagus | Outdated/Wrapped Legal Person Self Description is not Compatible with Clearing House

[typecastcloud]

Description

As a data space participant, I want to register connectors, without interruptions.

• We have a legal person document stored in portal database
  • Elbe Wrapper Legal Person
  • Tagus Wrapper Legal Person
  • Expired Legal Person
• which is referenced in "providedBy" URL when requesting credentials from SD factory.
• These documents are not readable/valid from from clearing house side.

Acceptance Criteria

• Connector have to successfully register with created connector credential if legal person document is tagus ready and otherwise valid
• Connector have to successfully register without creating connector credential if legal person document is outdated
• Middle state of skipped connectors are documented for operators as known behavior

Additional Information

1. Clearing house: providing a "middle state" for connector registration document callback POST, where
2. Portal: can decide to activate connectors until new issuance renewal process is in place.

[typecastcloud]

@SanaSalem01
At least 3 testcases:

1. Company with Elbe legal person document registers connector
   • Connector is activated
   • No document is created
2. Valid Tagus Legal Person Document exists
   • Connector is activated
   • Valid connector credential document is stored
3. Company without legal person document is unable to create connector (maybe not intended behavior since toggling sd off and on should not be a real use case)
   • Connector registration fails ?
   • No document is created
4. Pending: Maybe some outdated wrapper cases in between transitioning to tagus
   • Connector is activated
   • No document is created

[typecastcloud]

Aleksandar Kelecevic will provide additional details on our decision. Please also update on Monday if any new issue pops up.

[evegufy]

@typecastcloud @SanaSalem01 I recommend to also look into possible changes needed on frontend side - the missing self description could cause displaying issues for instance.

[akelecevic]

@typecastcloud There are at least two issues here - I address them separately, but a single implementation should cover both.

Context
During the company onboarding process, a Legal Person Compliance credential is created and sent from the Clearing House to the Portal via the callback. Later, during the connector registration, the same Legal Person credential, together with the one describing the connector, is again sent to the Clearing House, and causes a failure.

There are two issues at play here:

1. The response sent by the Clearing House during the onboarding, is similar, but not identical to what the Clearing House expects as the input during the connector registration call. This causes all connector registrations to fail, independent of when the onboarding took place. Problem here is the shape of the data, not the actual content.
2. Credentials submitted during the connector registration might contain a mix of Elbe (old) and Tagus (new) credentials, which is not considered valid and would fail the onboarding.

Way forward

For the first issue, Clearing House will:

• In the payload of the callback, provide the output exactly as returned by the Gaia-X Compliance service, without introduction of any custom data models/schemas. Note: the outer wrapper, containing the externalId and the status/message would still stay as-is.
• The selfDescriptionDocument would then be similar to:

{
  "@context": [
      "https://www.w3.org/2018/credentials/v1",
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    { ... },
    { ... },
    { ... },
    { ... }
  ]
}

containing a single Verifiable Presentation, with several Verifiable Credentials. Last one is always the Compliance credential, and the top ones are signed versions of the credentials passed in the input (Legal Person, Legal Registration Number, Terms and Conditions)

Important: The input for the subsequent calls to the Clearing House IS NOT equal to the one above. The compliance credential (last one) is not expected as part of the input.

For that, there are several options:

1. Clearing House returns exactly what it wants to see - not possible, since compliance credential will then not be sent to the Portal
2. Clearing House filters out the compliance credential on the input side - non-standard Clearing House behaviour, ideally avoided
3. SD-Factory filters out the compliance credential before sending it out - preferred
4. Portal stores two documents, on for the compliance credential itself, the other one for the rest
   @evegufy @typecastcloud We might need to catch-up on this

For the second issue, Clearing House will:

• Differentiate between failures caused by the "usual" failure reasons (e.g., identifier not correct) and the "outdated" failure reasons (e.g., version mismatch between the submitted credentials)
• It's up to the Portal to decide which of these to treat as process blockers and which to pass, possibly marking them as skipped.
• To preserve backwards compatibility, proposal is to leverage the existing Failure status for the outdated, because for all intents and purposes, this is a failure.
• A dedicated error code will be transmitted as part of the failure message to indicate the reason for the failure. This also allows us to be more granular with failure reasons in the future

[akelecevic]

Possible process flow, based on the summary above. Green is existing, red is new implementation required by this issue.