Several supported options

[alenhorvat]

Hi.

EBSI, as multi use-case project, supports several options for

• revocation
• VC format
• Signing algorithms

However, the profile definition requires only one value.

[cre8]

@alenhorvat we had this discussion in the last meeting that a profile has sometimes multiple values.

In case we allow multiple entries for one resource, we are not able to compare profiles by their features (e.g. one of the revocation features supports privacy, the other one does not. What does that mean for the privacy aspect looking at the whole profile?

The current solution is to define multiple profiles with a unique name, like the case with anoncreds:

• Anoncreds can be realised with did:indy, did:web, did:sov: so we would call the profile "Anoncreds with did:indy", and so on.

The resulting TODO out of this question is how to we want to define a profile and what is the outcoming purpose of it

Your mentioned case with EBSI is special because in my opinion it is not a profile, but just a system for key management (it was added to the list before we challenged the criteria of a profile definition)

The TODO of this question is to remove all incomplete profiles from the list and to only allow the onces that have a specification like MDL that is defined by ISO.

[alenhorvat]

Hi. Ok. Then we'll register several profiles accordingly.

EBSI does contain several profiles (for both B2C/G2C and B2B/G2G VC exchange) and "system for key management" is only one of its features. Interesting to hear such a conclusion since the 2 main profiles have been presented in an OWF meeting.

See also end-to-end conformance tests: https://api-conformance.ebsi.eu/docs/wallet-conformance Here you can find more information about key management, revocation, selective disclosure, ... https://api-conformance.ebsi.eu/docs/specs/credential-status-framework/credential-status-strategies

Thank you.

Issue can be closed.

[cre8]

The question how to define a profile is not fully answered yet. The idea with referencing only one resource allows you to query profiles like "show all profiles that have crypto agility".

Do you know in which meeting it was? Maybe the recording of it can give me some good information :)

[cre8]

The EBSI profile is btw a good example for the different use cases and problems. In the case we define a separate profile for each possible combination. EBSI has 5 credential status VCs and two methods for the holder (legal entities and natural persons). So only with these parameters we would have 10 different profiles that needs to be added to the list. But not every profile with each selection has its own specification. So this would be a good reason to allow 1 to n linking for resources.

[cre8]

Reopening this issue since the question is not really answered.

[alenhorvat]

Hi.

It was a meeting where other profiles like mDL, Duch profile, HAIP and others were presented. @tlodderstedt can maybe help to identify the exact meeting.

Note that ISO mDL has a similar structure (this is only 18013-7)

• there are several signing algorithms (I believe the number of supported algorithms is > 5)
• 2 revocation approaches: CRL, OCSP
• 2 presentation protocols (mDL REST API and OID4VP) - OID4VP has at least two options for client_schema_id - hence at least 3 variants

I also understand the simplicity/complexity of expressing the different profile(s) where some are very specific and focused on a single use case (or even closed systems), whereas others need to cater for a larger number of use cases (where we know that different variants appear due to different business/security/privacy requirements). It is also important to understand from which businesses the different profiles originate and where they are being tested/piloted/used. We learned at EBSI that something that works well for one use case might require a lot of bending to fit it into another use case.

Great work! Thank you very much. It's not an easy task.

[tlodderstedt]

I agree, ISO mdoc needs to be further detailed into multiple profiles. In the end, the number of profiles makes transparent how many options implementations need to support. Perhaps that inspires people to remove option to make interoperability easier.

Note, however: ISO does not have a revocation mechanism for mdocs. It uses the expiration to control validity. Protocols are out of scope for credential formats (at least for now).

[alenhorvat]

Great. I agree. Let us know whether 1:1 or 1:n approach is going to be used/supported.

ISO manages all key revocations using CRL and/or OCSP (issuer keys, device keys), depending on the key/certificate type. Without a valid device key and device certificate (x509), the mdoc cannot be presented. Hence mdoc can be revoked indirectly by revoking the device key.

ISO profile needs to support both: x509 and mdoc-related credential formats.

(outside of the scope of this issue)

Edit: I remember we also filled out a table for OID4VP/OID4VCI profiles. Is that managed elsewhere? (it was a google doc shared with us after the presentation)

[tlodderstedt]

You are mixing the format of the credential and the format used to convey keys and trust chain information. Credential revocation is about the first aspect.

Indeed, revoking the key/trust chain of an issuer might invalidate the credentials issued by that issuer (if there is no time bound validation, e.g. using trust lists) is in place. I would not see that as credential revocation. Perhaps we need to tighten the definition of this category a bit.

Indeed, a certain format (x.509) can also be a credential format in which case CRL and so on kick in. But that's a different profile (one could meta in relationship to mdoc).

[cre8]

I am closing this since we agreed in the past, that a profile is only having one resource (like one signing algorithm). Otherwise it is not possible to compare them: when my profile has two signing algorithm, but only one of them supports ZKPs, does the profile then supports it or not? I am not a fan of (*), so it seems to be cleaner to add multiple profiles where the user can filter them.