-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OID credential issuer identifier #396
Comments
Could you share a bit more about the design of your system, e.g. what credential format this is for etc please? |
This is for a ldp_vc credential. Example
Every issuer will have a unique oid identifier, valid and unique in the entire world. |
Thanks for adding the extra detail, that helps! I get it, it's an interesting idea, and in my personal opinion I think it's technically allow in the VCI specification. However I'd very strongly discourage anyone from actually implementing in that way though because it will hugely harm interoperability. I appreciate the concerns about https relying on domain names that can change over time, but in practice it's very rare that anyone ever 100% stops using a domain (registrations tend to stay in place for a very long time, just with permanent redirects to new sites), and the issuer urls aren't intended to be visible to the end users so it really doesn't matter if they (say) have an old brand name in them after a re-brand/rename happens. If you're really sure it's a problem there are ways to mitigate it whilst still using https, for example having a central directory type service that hosts the well-known files for all issuers in an ecosystem, however I'm not sure that is necessary. If we want these specifications and VCs in general to be successful we need to do our best to all implement these standards in common ways, and this will also reduce the burden on implementers. |
Could you please explain me in more detail about the interoperability concerns? From our architectural perspective, it seems that we will always require a Central Registry to ensure the authenticity of credential issuers and provide a reliable source for their public keys. |
Hi Fabrii,
Sure! Basically it's that no one else is doing this, so it wouldn't be interoperable with other ecosystems and "off-the-shelf" verifiers, wallets & issuers likely wouldn't be usable.
This doesn't need OIDs though. You can do a central registry just by centrally hosting the .well-known endpoint, or by using OpenID Federation, or by having a list of trusted issuer urls somewhere.
Unfortunately requiring special code to cope with one implementation or ecosystem isn't going to help with general interoperability. As another example, it's probably likely the OpenID Foundation conformance tests for the VCI & VP protocols would fail implementations where the issuer is an OID - because the purpose of those tests is generally to ensure implementations both conform to what is defined in the standard and are interoperable. |
Would this be a correct approach?
I am having a hard time understanding where the issuer's public keys should be published and the correct value for the verificationMethod attribute, if we are not using did:key. For example, if my issuer id is "https://myissuerdomain.com", my verificationMethod would be "https://myissuerdomain.com#1"? How can a documentLoader load the associated "DID Document" used to validate this signature, in a standarized way? Are we forced to use did:key and DID Configuration to support interoperability? Thank you very much. |
Other than OpenID Federation I'm not aware of any specification that currently defines the format for such a list (maybe other people might know).
I think this kind of thing is credential format specific. For instance if you were using SD-JWT VC the keys are fetched from a .well-known location as documented here: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-05.html#name-jwt-vc-issuer-metadata I'm not so familiar with the ldp_vc credential type (in Europe we're only really seeing mdoc & SD-JWT format credentials getting used), so that might be something someone else can answer. |
I was missing that crucial part of In our case (ldp_vc), I picture three options:
As a side note, I would be interested to know, if possible, why EUDI decided not to use ldp_vc. I found information about the decision, but I couldn’t find the reasoning behind it. Thank you! |
I think you have reached the limit of my knowledge on
I can't give any kind of official answer on this. My guess based on speculation and personal intuition and speaking purely as an individual contributor would be something like this:
My guess would be that once they selected those two they didn't have any use cases that required It would be nice if we could have a globally consistent decision, but given the various vested interests I realistically don't think that is going to happen soon. All that we can say is given the direction the EU is going is looks like there will be large numbers of verifiers that will likely have support for both mdocs and SD-JWT VC, and given the legal mandates in the EU in about 2 years time there'll be upto 450 million users with access to government endorsed wallets that support these formats. You can make a similar argument around USA states and OID4VCI is strives to be credential format agnostic, i.e. that it can be used regardless of the credential format selected. |
Hi @jogu. You've been incredibly helpful, so thank you! Regarding my verificationMethod question, I believe I might ask for guidance on https://github.com/w3c/vc-data-model.
|
Hi!
We can see in the specification the following text:
We were thinking about using OIDs, managed by ISO & ITU-T (ISO/IEC 8824-1 Information Technology - Abstract Syntax Notation One (ASN.1))
For example:
"issuer": "urn:oid:2.16.858.0.0.0.3.0",
Is this aligned with the spec?
Thank you
The text was updated successfully, but these errors were encountered: