[Openid-specs-ab] OpenID4VCI: relation between the metadata's credential_issuer and the issuer of an issued verifiable credential

Tue Jan 10 20:02:55 UTC 2023

Hi Pedro,

> 1) Is it OK to have a mismatch between the metadata `credential_issuer` and the issued VC `issuer` field?
One way to provide this (and is pretty mainstream in VC ecosystem from what I know) is to use Well Known DID Configuration (identity.foundation)<https://identity.foundation/specs/did-configuration/> specification, which provides a bi-directional binding btw a DID and a domain (which can be credential_issuer URL) - aDID Document obtained from an `iss` DID would contain a domain where a JSON document containing a DID is hosted. (whether this is needed with did:web where DID Document is already hosted under a domain is debated)

I think it would be sufficient?

Would be great if you could raise an issue - sounds like we need an implementations considerations section or equivalent.

Cheers,
Kristina

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf Of Pedro Felix via Openid-specs-ab
Sent: Tuesday, January 10, 2023 10:06 AM
To: Artifact Binding/Connect Working Group <openid-specs-ab at lists.openid.net>
Cc: Pedro Felix <pmhsfelix at gmail.com>
Subject: Re: [Openid-specs-ab] OpenID4VCI: relation between the metadata's credential_issuer and the issuer of an issued verifiable credential

On the example above I meant "issuer" and not "id" as the top-level field.
{
   (...)
   "issuer": {
       "id":"did:example:76e12ec712ebc6f1c221ebfeb1f",
       "name": "Example University"
       "another_id": "https://credential-issuer.example.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredential-issuer.example.com%2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tha7kX1WSgB5tukx8yPAa%2Ff09EICIwGTB%2FXzkCf%2BUYI%3D&reserved=0>"
   }
}

On Tue, Jan 10, 2023 at 4:21 PM Pedro Felix via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:
Hi David,

Thanks for the answer.
Just to confirm I'm understanding your proposal correctly...

- The W3C VC would have something like (following example https://www.w3.org/TR/vc-data-model/#example-usage-of-issuer-expanded-property<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fvc-data-model%2F%23example-usage-of-issuer-expanded-property&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ye2hAqDn%2BOjMarJ3ArggfWF3%2BzMHsw7wm%2FToaM7rGyM%3D&reserved=0>)?

{
   (...)
   "id": {
       "id":"did:example:76e12ec712ebc6f1c221ebfeb1f",
       "name": "Example University"
       "another_id": "https://credential-issuer.example.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredential-issuer.example.com%2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tha7kX1WSgB5tukx8yPAa%2Ff09EICIwGTB%2FXzkCf%2BUYI%3D&reserved=0>"
   }
}

- "another_id" field name would be aligned with the field name inside the metadata. For instance, "another_id" could be "credential_issuer" (the current name in the OIDC VCI metadata)?

Did I understood it correctly?
I was thinking on taking a different route, where the OIDC VCI metadata would have an additional field with alternate issuer IDs, namely to avoid adding restrictions into the W3C VC shape (i.e. the VC issuer could still be a simple URI string)
Metadata example
{
   "credential_issuer": "https://credential-issuer.example.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredential-issuer.example.com%2F&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tha7kX1WSgB5tukx8yPAa%2Ff09EICIwGTB%2FXzkCf%2BUYI%3D&reserved=0>",
   "alternate_issuer_ids": ["did:example:76e12ec712ebc6f1c221ebfeb1f"],
   "credential_endpoint": "...",
   "credentials_supported": [...],
}
The Wallet would then check that the issued VC has an issuer matching credential_issuer or one of the alternate_issuer_ids.
I'm assuming that for the final VC verifier, the OIDC issuer URL is not meaningful, only the VC issuer (string value or id field).

It is interesting to have the OIDC VCI issuer URL in the VC, however I'm afraid that some profiles may restrict the VC issuer to be an URI and not an object.

Should I create a BitBucket issue exposing the problem and describing both solutions?

Thanks,
Regards,
Pedro

On Tue, Jan 10, 2023 at 11:11 AM David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>> wrote:

Hi Pedro

the W3C VCDM issuer property can be an object or a URI. If the issuer uses the object form to identify itself then it is possible to have both a DID and a URL inside the object. We have used this format in our interop testing.  In order to align the OpenID4VCI draft with the VCDM one way could be to standardise the name of the property for the issuer's URL so that the property name inside the metadata matches the property name inside the issuer object of the VC.

Do you want to raise this as an issue with sourcetree?

Kind regards

David
On 09/01/2023 17:34, Pedro Felix via Openid-specs-ab wrote:
Hi all,

I've a question about the OpenID4VCI draft specification and the relation between credential issuers and the `credential_issuer` field on both the metadata and the credential offer.
According to OpenID4VCI draft 10, `credential_issuer` needs to be an URL and there is a discovery process dependent on that fact. However, the issuer on a concrete verifiable credential (VC) may not be an URL.
For instance, the W3C VC data model allows the `issuer` field to be an URI, namely a DID based URI. Due to this, the `credential_issuer` metadata field may not match the `issuer` field on a W3C VC issued by that issuer, which seems strange. Wouldn't that be similar to having an ID token with an `iss` that doesn't match the metadata `issuer`?
Note that some VC profiles may mandate the VC issuer to be a DID with a specific method (e.g. EBSI), so the issuer doesn't have the freedom to use a URL instead.
This also relates to the `aud` to use on a JWT proof token, sent on a credential request, which I presume should match the metadata `credential_issuer` but may not match the issued VC `issuer`.
So,
1) Is it OK to have a mismatch between the metadata `credential_issuer` and the issued VC `issuer` field?
2) If not, could this be addressed by adding more information in the metadata, allowing a non-URL issuer to be announced there, eventually scoped to each `credentials_supported` entry?

Thanks.
Regards,
Pedro

_______________________________________________

Openid-specs-ab mailing list

Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KqwZlwwW3ImaiYoEyNG3DI9rTd8H7VwM%2FkNsfsUtmb0%3D&reserved=0>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KqwZlwwW3ImaiYoEyNG3DI9rTd8H7VwM%2FkNsfsUtmb0%3D&reserved=0>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
https://lists.openid.net/mailman/listinfo/openid-specs-ab<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=05%7C01%7CKristina.Yasuda%40microsoft.com%7Cd259476e6caf44e2b3b708daf33553f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638089709508782349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KqwZlwwW3ImaiYoEyNG3DI9rTd8H7VwM%2FkNsfsUtmb0%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230110/539aa373/attachment-0001.html>