Compatibility Issues between ssi-credential-issuer and managed-identity-wallet

[thackerronak]

Issue Summary

As we are planning to align managed-identity-wallet with the current ecosystem for the upcoming 24.08 or 24.12 release, we identified alignment issues with the ssi-credential-issuer app and the managed-identity-wallet app.

Detailed Findings

1. Credential Creation and Signing Process:

   • ssi-credential-issuer: The processes of credential creation and signing are separated into distinct steps.
   • managed-identity-wallet: Both the creation and signing processes are combined into a single step.
   • Impact: This discrepancy in the workflow causes integration issues and necessitates modifications in either or both applications to ensure compatibility.

2. Wallet Service Endpoint Naming and Parameter Alignment:

   • ssi-credential-issuer: The endpoint names within the wallet service are hard-coded and do not match those in the managed-identity-wallet.
   • managed-identity-wallet: Uses different naming conventions and the request/response parameters are not aligned with those in ssi-credential-issuer.
   • Impact: This misalignment in endpoints and parameters leads to communication failures between the two systems. Standardizing endpoint names and aligning request/response parameters are essential for interoperability.

3. Revocation Endpoint and Status List Schema:

   • ssi-credential-issuer: The revocation endpoint is implemented and uses the statuslist2021 schema.
   • managed-identity-wallet: Revocation functionality is still under development, and the revocation endpoint is not yet exposed. The plan is to use the bitstring status list schema.
   • Impact: The difference in schemas and the absence of a revocation endpoint in managed-identity-wallet results in inconsistencies. Both applications need to adopt a unified approach to revocation to ensure compatibility.

We discussed this with @OSchlienz and @evegufy , and have created an issue here.

[jjeroch]

Please close the ticket, raise a feature ticket @OSchlienz that should come from you if you see an issue for the MIW and validate first the existing features please since there seems to be overlaps.
eclipse-tractusx/sig-release#647

[OSchlienz]

Hi @jjeroch, the ticket eclipse-tractusx/sig-release#647 is adressing actually the topic to have a single step for signing. This will be part of the planning, correct?

[evegufy]

Hi @thackerronak thank you for collecting the topics!

regarding the first point, eclipse-tractusx/sig-release#647 covers it.

Regarding the seconds point, we opened this issue #226 for more configurability, does that cover everything?

Regarding the third point, I think the credential issuer isn't the only component working with the statuslist2021 statuslist: as far as I know also the EDC doesn't support the bitstring statuslist, how do you handle the connection with the EDC in that regard?

[OSchlienz]

Hi @evegufy, IATP builds on biststring statuslist https://github.com/eclipse-tractusx/identity-trust/blob/0.8.1/specifications/credential.issuance.protocol.md#8-vc-revocation

[thackerronak]

Hi @thackerronak thank you for collecting the topics!

regarding the first point, eclipse-tractusx/sig-release#647 covers it.

Regarding the seconds point, we opened this issue #226 for more configurability, does that cover everything?

Regarding the third point, I think the credential issuer isn't the only component working with the statuslist2021 statuslist: as far as I know also the EDC doesn't support the bitstring statuslist, how do you handle the connection with the EDC in that regard?

1. 👍

2. I believe Make application name and wallet paths configurable #226 specifically addresses the path of the wallet app but does not include details about request and response parameters.

3. You are correct. Currently, EDC does not support bitstring status lists. However, they have created a task for it: 4357. Regarding MIW, it is still in under development for revocation, so the connection with EDC has not been established yet.

[evegufy]

Hi @evegufy, IATP builds on biststring statuslist https://github.com/eclipse-tractusx/identity-trust/blob/0.8.1/specifications/credential.issuance.protocol.md#8-vc-revocation

Hi @OSchlienz the link for the Status List https://www.w3.org/TR/vc-status-list/ you're referring to, must have forwarded a couple of weeks ago still to https://www.w3.org/TR/2023/WD-vc-status-list-20230427/, which - yes - by now that one is outdated, but certainly wasn't outdated when the edc and the credential issuer built their implementation on it. Are you saying you weren't aware that the edc and the issuer is using the statuslist2021?
Just because this link forwarding changed, it doesn't mean that all our components using the statuslist2021 (edc, issuer) automatically adapt to it. Also, I think this is might be a network breaking change, so not a viable change for the release 24.12. It needs to be planned accordingly on sig-release level https://github.com/eclipse-tractusx/sig-release/issues
I only way I see for MIW to be part of 24.12, is to change to the statuslist2021.

[evegufy]

Hi @evegufy, IATP builds on biststring statuslist https://github.com/eclipse-tractusx/identity-trust/blob/0.8.1/specifications/credential.issuance.protocol.md#8-vc-revocation

Hi @OSchlienz the link for the Status List https://www.w3.org/TR/vc-status-list/ you're referring to, must have forwarded a couple of weeks ago still to https://www.w3.org/TR/2023/WD-vc-status-list-20230427/, which - yes - by now that one is outdated, but certainly wasn't outdated when the edc and the credential issuer built their implementation on it. Are you saying you weren't aware that the edc and the issuer is using the statuslist2021? Just because this link forwarding changed, it doesn't mean that all our components using the statuslist2021 (edc, issuer) automatically adapt to it. Also, I think this is certainly a breaking change, so not a viable change for the release 24.12. It's network breaking and needs to be planned accordingly on sig-release level https://github.com/eclipse-tractusx/sig-release/issues I only way I see for MIW to be part of 24.12, is to change to the statuslist2021.

or to be more precise, the components (edc, issuer and miw) should support both statuslists, so that the change to bitstring isn't breaking. in any case, miw needs to support statuslist2021 as well.

[DominikPinsel]

Hi @evegufy, IATP builds on biststring statuslist https://github.com/eclipse-tractusx/identity-trust/blob/0.8.1/specifications/credential.issuance.protocol.md#8-vc-revocation

Hi @OSchlienz the link for the Status List https://www.w3.org/TR/vc-status-list/ you're referring to, must have forwarded a couple of weeks ago still to https://www.w3.org/TR/2023/WD-vc-status-list-20230427/, which - yes - by now that one is outdated, but certainly wasn't outdated when the edc and the credential issuer built their implementation on it. Are you saying you weren't aware that the edc and the issuer is using the statuslist2021? Just because this link forwarding changed, it doesn't mean that all our components using the statuslist2021 (edc, issuer) automatically adapt to it. Also, I think this is certainly a breaking change, so not a viable change for the release 24.12. It's network breaking and needs to be planned accordingly on sig-release level https://github.com/eclipse-tractusx/sig-release/issues I only way I see for MIW to be part of 24.12, is to change to the statuslist2021.

Given that the currently implemented specification became obsolete on November 23, 2023 (when the name changed from StatusList2021 to BitStringStatusListEntry), I believe it would be more effective to align our implementation with the current specification. This approach prevents the inefficiency of adopting an outdated specification and then needing to revise it again in the near future.

If we intent to use the StatusList2021 it is also becomes necessary to release a new version of the IATP protocol, so that it is in line with the current implementation.