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

[Pedro Felix]

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
)?

{
   (...)
   "id": {
       "id":"did:example:76e12ec712ebc6f1c221ebfeb1f",
       "name": "Example University"
       *"another_id": "https://credential-issuer.example.com
<https://credential-issuer.example.com>" *
   }
}

- "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",
  * "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> 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 listOpenid-specs-ab at lists.openid.nethttps://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230110/af876d5a/attachment.html>