Source Data & Display of Issuer Name

[kayaelle]

When the issuer is in one of the registries that the verifier knows about (currently one of the DCC registries), the issuer name should be pulled from the listing in the registry and the issuer verification should be true.

If the issuer is not located in the registry, the issuer name should be sourced from the credential data and the issuer verification should be false. For open badges, the issuer name is located in issuer.name.

If there isn't an issuer name available to display, the issuer name field should not display and the issuer verification should be false.

[jchartrand]

@kayaelle @bmuramatsu @dmitrizagidulin

Should we say something (at verification time) if the issuer name in the registry doesn't match the issuer name in the credential (but they share the same DID)?

With maybe a message like "The name of the issuer in your credential doesn't match the name of the issuer in the DCC registry". And show both names?

And for that matter, should such a discrepancy cause verification to outright fail?

[kayaelle]

Good question - Are we doing any DID auth on the issuer?

[jchartrand]

@kayaelle I'm not sure I know what you mean by 'DID auth on the issuer' in this case?

[kayaelle]

I meant, do we authenticate that the VC is signed by the DID that is in the issuer.id? I'm assuming we do and should have stated that when I wrote the issue... So it should be that did auth passes and the issuer is on a DCC registry.

If that's true then it shouldn't really matter that the names don't match and the issuer name in the registry should be displayed. That said, it'd be helpful if we log those kind of errors so that we can inform the issuers of their typos (not scope of this issue but something we could talk about)

[jchartrand]

Indicating at verification time that there is a difference between the issuer's name in the credential and in the registry would be one more small safeguard against someone (at signing time) fraudulently changing the issuer name (e.g. from Trump University to Harvard University). You could imagine this becoming a potential issue later if there were a single registry of all the DIDS of all universities. At that point there might be fewer safeguards on issuance at some institutions, and someone might try to issue a fraudulent cred, claiming it was from a different university.

You are right that if the verifier always displays the registry name then the deception wouldn't work, but imagine the case where there isn't a display, i.e, some automated verification of credentials by a company's recruitment portal. At verification time the deception wouldn't be caught, and then later the credential might be displayed without using the registry. So, in that case really the recruitment portal's verifier should compare the issuer names. But if they are, then maybe we should too, just to be consistent.

Something like LInkedIn would be another example of where the LinkedIn verifier would have to confirm that the issuer name in the cred matches that in the registry. Otherwise, again, verification might pass, but then the wrong issuer name might be shown in LinkedIn (unless LinkedIn pulls in the issuer name from the registry, but that seems harder than just enforcing that the issuer in the cred matches that in the registry.)

[kayaelle]

Excellent points - let's discuss further in our next meeting. We will want @bmuramatsu @dmitrizagidulin to chime in.

Scenarios are:

• issuer name is in the vc and matches the registry
• issuer name is in the vc and doesn't match the registry
• issuer name is not in the vc but is in the registry
• issuer name is not in vc and is not in registry

Does that cover them all?

Edit: more scenarios that are related:

• vc is not signed by the did in the vc
• Issuer did in VC different than did in registry

[kayaelle]

For continued discussion:

We discussed at tech call and there's a suggestion on the table to only read issuer name and logo from the registry and disregard those properties if they are in the VC. This would mean that anyone in DCC registries could leave these properties out of their VCs. If an issuer is not located in the registry, then the issuer name and logo in the vc (if provided -- not required by OBv3).

Issuer logos are not currently in the registry and would need to be added.

Whatever is decided here will need to be applied to the LCW as well.

[bmuramatsu]

We discussed at tech call and there's a suggestion on the table to only read issuer name and logo from the registry and disregard those properties if they are in the VC.

This sounds good to me, it retains the registry as the primary determiner of info about the issuer for verification purposes.

This would mean that anyone in DCC registries could leave these properties out of their VCs.
Would we recommend this? Or would we recommend that they include those properties in their VCs? Or remain silent?

If an issuer is not located in the registry, then the issuer name and logo in the vc (if provided -- not required by OBv3).
Would a credential with an issuer not in the registry show as verified in our verifier or wallet?

[kayaelle]

ok - since this is a potential change in scope @jchartrand please hold on this and we'll piece together a plan at next tech call.

[kayaelle]

Since issuer logo has been pulled into this issue, posing these questions:

• does it matter if the issuer logo changes over time or is unavailable?
• what will the value of the logo be (base65, url)?
• if url, how will its persistence be determined?