Skip to content
This repository has been archived by the owner on Dec 9, 2024. It is now read-only.

Consider a 2-layer profile (add end to end profile) #79

Open
ArPhil opened this issue Sep 14, 2023 · 1 comment
Open

Consider a 2-layer profile (add end to end profile) #79

ArPhil opened this issue Sep 14, 2023 · 1 comment

Comments

@ArPhil
Copy link

ArPhil commented Sep 14, 2023

In the last call on 2023-09-13 the concern was raised, that the current idea of a "credential format profile" does not provide that much value to parties which are interested in the credential format comparison matrix. The reason for this concern was, that a credential format profile itself does not guarantee any end to end interoperability between two interacting entities, since common flows like issueing or presenting a credential involve more than just a credential profile / format (e.g. exchange protocols, source of key material (e.g. DID Method, Revocation, ...).

The (current) goal of this working group is:

This SIG is dedicated to maintaining information about available credential formats for the benefit of OWF projects and the wider community.

I would like to propose the extension of that goal by not only elaborating a credential profile matrix as currently happening but also to work on a (higher) end to end interop profile matrix which includes (besides credential profiles) additional parameters like exchange protocols, DID Methods, Revocation, Key Rotation,...

In my understanding a credential format is only one single parameter of this the end to end interop profile which we sometimes also call "tech stack". Although we cover aspects like DID Methods, Revocation, Key rotation and others in the credential profil matrix, I believe the parameters mentioned here belong to the higher end to end profile since:

  • Parameters like "Infrastructure for key resolution" do not concern a credential profile directly. I would rather say, that the source of the key material for a credential profile itself is not important at first place. However, for an end to end profile it is, since both parties have to understand and be able to resolve the key material of e.g. an issuer. The same applies to key rotation, since this is closely tied to the "VDR" any key material comes from.

  • Most of the (credential) exchange protocols are agnostic to a credential profile. Therefore I see them also on the higher end to end interop profile and not in the credential profile itself.

  • Some revocation mechanisms are tied to a credential format / profile, but not all. Therefore I see them also on the higher end to end interop profile and not in the credential profile itself.

I believe there can be more arguments found for the separation into "credential profile" and "end to end profile". From my point of view a clear separation would help to set the scopes for each properly.

But as introduced in the beginning, this will robviously esult in more effort than planned with regards to the original goal of the SIG.

What is your opinion on that?

@ArPhil ArPhil changed the title Consider a 2-layerd profile Consider a 2-layer profile (add end to end profile) Sep 14, 2023
@cre8
Copy link
Contributor

cre8 commented Sep 19, 2023

I agree that the current matrix is nice to compare the different resource like the differences between different key management systems. Defining a profile so that they are comparable seems to be trickier than we thought in the first place.

As you pointed out the benefit could be different for multiple parties. From the perspective of a wallet and agent user they need also compliance on the exchange protocol. And some profiles are already implementing one so adding a new resource would make no difference to the current approach of a matrix.

But we also had the mention that a profile could support multiple key management systems, making it very difficult to compare profiles (since e.g. crypto agility depends on your chosen credential format inside the profile).

I am not sure if we can draw a line between to layers (what is required and what is nice to have). Maybe we will spend more time choosing a layer than by defining the criterias of each resource. So I would like to prefer to go just with one layer, but we could definitely try to group resources (like the issuance protocol and the presentation protocol are grouped as transport).

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants