Some thoughts to make DIDs optional in the Linked VP spec

[TimoGlastra]

I saw a presentation of Linked VPs at DICE recently, and already heard about two other projects adopting Linked VPs:

• did:tdw using the /whois specification.
• A pilot project in the Netherlands to publicize credentials about an organization

After reading the specification, I like the concept and think it could be a really easy way to publicize VPs, however I think the specification could be generalized a bit to allow it's usage without DIDs as well. Maybe this should be a separate specification, but I wanted to share some thoughts on how I see see this could work:

• Keep the LinkedVerifiablePresentation service endpoint type that can be included in a did document as is, but it is not required.
• In addition, define a .well-known URI for publicly hosting a linked VP (more a Well Known VP in this case). If you have the domain of an entity (e.g. SD-JWT VCs describe two methods where you use a https:// uri as the iss identifier), you could fetch the well-known Linked VP and verify it.
• Make the VP file an array of VPs. Each entry will be an object with format which would be identifiers from the DIF Claim Format Registry. This could support ldp_vp, jwt_vp, but also additional and new formats such as vc+sd-jwt, acdc, etc. The type of the vp value would depend on the format used (can be string, objects, etc..). I think an array could also have benefit so you don't have to re-generate the linked vp every time you want to add a new VC, but you could just add a new VP to the list.

This way the spec could evolve with any type of issuer identifier, still be compatible with DIDs, but also allow to be used without DIDs, can be extended with new format types. By making it an array you can include multiple VPs at the well-known URI.

[peacekeeper]

@TimoGlastra I can understand why there may be interest in discovering VPs from .well-known rather than using DID Resolution.

But when I read things like the following:

any type of issuer identifier

can be extended with new format types

Then all I can think is that this is exactly what DIDs do! They provide a common syntax and common resolution format for any type of underlying identifier system. There is no need to build an extensibility or abstraction mechanism that supports DIDs plus other identifiers, because DIDs already ARE that mechanism.

[jceb]

@TimoGlastra thank you for your feedback. Here are some additional thoughts:

I saw a presentation of Linked VPs at DICE recently, and alreay heard about two other projects adopting Linked VPs:

* did:tdw using the `/whois` specification.

* A pilot project in the Netherlands to publicize credentials about an organization

After reading the specification, I like the concept and think it could be a really easy way to publicize VPs, however I think the specification could be generalized a bit to allow it's usage without DIDs as well. Maybe this should be a separate specification, but I wanted to share some thoughts on how I see see this could work:

* Keep the `LinkedVerifiablePresentation` service endpoint type that can be included in a did document as is, but it is not required.

I'm not sure I understand your request correctly. The type property is not optional in the DID spec. Providing LinkedVerifiablePresentation as semantic information is a core part of this specification and won't be changed.

* In addition, define a `.well-known` URI for publicly hosting a linked VP (more a Well Known VP in this case). If you have the domain of an entity (e.g. SD-JWT VCs describe two methods where you use a https:// uri as the `iss` identifier), you could fetch the well-known Linked VP and verify it.

As Markus pointed out, DIDs are much more general purpose identifiers that are not bound to the web. While I understand your request of specifying a .well-known path for hosting presentations, it leaves unanswered many other other questions like:

• what is the identifier that's bound to this website?
• does very single identifier need to have their own domain name to host linked-vps?

If the identifier is a DID, then we don't need to specify .well-known because linked-vps will be discovered from the DID document. If the identifier is not a DID then a separate specification seems to me a better option.

The one case for .well-known that comes to my mind are DID methods that don't support service endpoints, e.g. did:key. However, two things must exist for this to work: a) a known domain name, e.g. coming from my browser b) a link between the domain name and a DID. Only then, it would make sense to look for linked-vps under a .well-known path. Since the link between a domain name and a DID is specified here https://identity.foundation/.well-known/resources/did-configuration/, I recommend specifying additional .well-known paths there. The linked-vp spec isn't concerned with the web.

* Make the VP file an array of VPs. Each entry will be an object with `format` which would be identifiers from the DIF Claim Format Registry. This could support `ldp_vp`, `jwt_vp`, but also additional and new formats such as `vc+sd-jwt`, `acdc`, etc. The  type of the `vp` value would depend on the format used (can be string, objects, etc..). I think an array could also have benefit so you don't have to re-generate the linked vp every time you want to add a new VC, but you could just add a new VP to the list.

• Multiple presentation formats are already supported by this spec so there's no need for a format property.
• Multiple linked-vp entries and an array of URLs for one linked-vp entry are also supported by this spec. Instead of updating an existing URL a new URL/file could be created and registered as another service endpoint in the DID document.
• Although this spec doesn't enforce any sub resource integrity configuration, it is better practice to not "silently" update an existing presentation without indicating this change also in the DID document.

This way the spec could evolve with any type of issuer identifier, still be compatible with DIDs, but also allow to be used without DIDs, can be extended with new format types. By making it an array you can include multiple VPs at the well-known URI.

As pointed out, this is a spec that is geared towards DIDs. I don't see how it could stay as simple as it is and serve other identifiers.