Any objections using certain parts of the spec as input/inspiration for a new interop profile?

[nklomp]

Hi All,

In NL several Dutch SSI vendors (TNO, Dutch Blockchain Coalition, Sphereon, Animo) have started work on a new interop profile which for now has the work title Dutch Decentralized Identity Profile (DDIP). One of the goals is to make some opinionated choices and have as little optionality in the profile, to allow for max interop between Dutch vendors and abroad.

The choices for v1 are basically the OpenID4SSI specs, non-ledger based DIDs (web/jwk), StatusList2021 and JWT VCs. Obviously the JWT VC Presentation Profile is pretty close to this and the https://ngiatlantic.info/ profile already. Some notable differences:

• Different DID methods (ion -> jwk, which also allows for X509 certs. Given DBC is involved and the 100+ DID methods, we didn't want to open the can of worms on ledger based DIDs)
• No well-known DIDs yet (still needs to be discussed in DDIP)

Obviously the JWT VC Presentation Interop profile will be mentioned in DDIP. Given the nature of DIF and this profile I know the answer already, but just wanted to take the royal route and to ask:

• Are you okay with us using some inspiration/input from this profile for creating DDIP?

A presentation on this profile a few weeks ago was very well received by Dutch parties, where consensus was that time has come for parties in the space to really become interoperable. So of course we now continue ;):

[Sakurann]

Sounds like the differences between the profiles would be small enough, we should try incorporate the needs of Dutch Decentralized Identity Profile (DDIP) in this profile - I think it will help everyone to build a larger interoperable ecosystem.

From the main differences you have noted, I think we should seriously consider adding support for did:jwk in this profile.

wrt No well-known DIDs yet (still needs to be discussed in DDIP) could you elaborate a little more on the reasoning? we could add a flag that allows to understand whether .well-known is required or not if we can't agree it is mandatory.

[Sakurann]

also I checked but Linked Domain Verification is optional - we can make it clearer if needed.

The checks can include Linked Domain verification of the Credential Issuer’s DID using the mechanism defined in Linked Domain Verification and Credential status validation of the VC(s) using the mechanism defined in Revocation.

[brentzundel]

From the main differences you have noted, I think we should seriously consider adding support for did:jwk in this profile.

Big +1 to this

[nklomp]

@Sakurann and I had a call the other day to discuss the above. Adding did:jwk would indeed help us a lot.

Regarding the No well-known DIDs yet (still needs to be discussed in DDIP). We simply haven't discussed it at this point in the DDIP. Since the profile is about did:web and did:jwk only, it also means that if domain binding to the DID is needed/required, one could use X509 certificates. Having said that, I do foresee we will add well-known DIDs as an optional part, as it doesn't prevent parties to exchange information with eachother, unless a party requires well-known DIDs. Another reason to act like our well-known did lib: Require well-known DIDs to succeed when they are defined, but do not fail if a DID/domain has no well-known DIDs.

[quartzjer]

Require well-known DIDs to succeed when they are defined, but do not fail if a DID/domain has no well-known DIDs.

Just a caution here, if you happen to mean automatic success if the HTTPS request to the .well-known endpoint fails to return a DID document, that can lead to DoS attacks in order to bypass validation.

That might not be what you're suggesting though :)

[nklomp]

Thanks. What we do in our library is looking at the serviceEndpoint in the DID first. Then if the mode is set to only check for well-known DIDs if present, we simply skip the whole validation if not present. Obviously it is up to the party using the library to determine whether they require linked domain validations, never use them or to only verify them if the DID has a respective service endpoint.

Well-known DIDs are nice for when a DID method or keytype doesn't have a link with a domain, but given both DID:JWK and DID:Web can be used with X509s a requirement to use well-known DIDs would be a bit much.

[quartzjer]

@nklomp thanks, I understand the context better now, my concern isn't relevant in that logic 👍

[dtmcg]

pending PR from @nklomp

[Sakurann]

we added did:jwk. is there any other delta that needs to be addressed between two profiles so that we can have one and not two?