You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Company Passport requires solutions aligning with Company Passport to support DIDs as identifiers.
As the ARF does not mention the usage of DIDs, listing this as a requirement in Company Passport may impose risks on the adoptability of Company Passport for organizational wallets. Especially since there are no required DID Methods, it will be hard to achieve interoperability.
As discussed on the Architecture WG call, it would be good to a) specify a set of required DID Methods. Additional did methods may be supported, and b) determine whether DIDs are really necessary for Company Passport to succeed.
I see a few advantages of adopting DIDs:
Alignment with EBSI and support for did:ebsi DID Method, although unclear what the role of EBSI will be in regards to eIDAS and the ARF
Support for Service Endpoints to dynamically discover endpoints used by an identifier, although this could be solved using well-known endpoints and metadata files as well, so I'd not see it as a strict requirement.
verifiable key rotation, although support for this depends on the did method used. If we choose e.g. did:jwk, did:key, did:web there's not really an advantage to using DIDs
From the above points, only alignment with EBSI has a strict requirement on usage of DIDs, so I think that will have a big influence on whether DIDs should be required.
I think adopting something like did:tdw could also be interesting, and will add extra value to the use of DIDs (which did:web doesn't really have over e.g. a well-known jwks_uri).
But still, if the ARF is not going to adopt DIDs, we should think about how this will interoperate with non-organizational credentials. Will government issue / accept VCs bound to DIDs even if not part of the ARF?
The text was updated successfully, but these errors were encountered:
I think instead of saying "ARF doesn't mention DIDs, so let's make them optional", we should try to explain to ARF people the value of using DIDs; I like your list!
Agreed. One of the reasons we created the list is to also explain why DIDs for company passport and DPP make sense. The goal of Company Passport is not to not have any specs or requirements that are not in the ARF. We follow the ARF as a basis. Nothing prevents us from other requirements. For instance I would also expect linked VPs to become an absolute requirement in Company Passport
Currently Company Passport requires solutions aligning with Company Passport to support DIDs as identifiers.
As the ARF does not mention the usage of DIDs, listing this as a requirement in Company Passport may impose risks on the adoptability of Company Passport for organizational wallets. Especially since there are no required DID Methods, it will be hard to achieve interoperability.
As discussed on the Architecture WG call, it would be good to a) specify a set of required DID Methods. Additional did methods may be supported, and b) determine whether DIDs are really necessary for Company Passport to succeed.
I see a few advantages of adopting DIDs:
did:ebsi
DID Method, although unclear what the role of EBSI will be in regards to eIDAS and the ARFFrom the above points, only alignment with EBSI has a strict requirement on usage of DIDs, so I think that will have a big influence on whether DIDs should be required.
I think adopting something like
did:tdw
could also be interesting, and will add extra value to the use of DIDs (whichdid:web
doesn't really have over e.g. a well-knownjwks_uri
).But still, if the ARF is not going to adopt DIDs, we should think about how this will interoperate with non-organizational credentials. Will government issue / accept VCs bound to DIDs even if not part of the ARF?
The text was updated successfully, but these errors were encountered: