<div dir="ltr"><div>Hi David,</div><div><br></div><div>Thanks for the answer.</div><div>Just to confirm I'm understanding your proposal correctly...<br></div><div><br></div><div>- The W3C VC would have something like (following example <a href="https://www.w3.org/TR/vc-data-model/#example-usage-of-issuer-expanded-property">https://www.w3.org/TR/vc-data-model/#example-usage-of-issuer-expanded-property</a>)?<br><br>{</div><div> (...)</div><div> "id": {</div><div> "id":"did:example:76e12ec712ebc6f1c221ebfeb1f",</div><div> "name": "Example University"</div><div> <b>"another_id": "<a href="https://credential-issuer.example.com">https://credential-issuer.example.com</a>" </b><br></div><div> }<br></div><div>}</div><div><br></div><div>- "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)?</div><div><br></div><div>Did I understood it correctly?<br></div><div>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)<br></div><div>Metadata example<br></div><div>{</div><div> "credential_issuer": "<a href="https://credential-issuer.example.com">https://credential-issuer.example.com</a>",</div><div> <b> "alternate_issuer_ids": ["did:example:76e12ec712ebc6f1c221ebfeb1f"]</b>,</div><div> "credential_endpoint": "...",</div><div> "credentials_supported": [...],<br></div><div>}</div><div>The Wallet would then check that the issued VC has an issuer matching <b>credential_issuer</b> or one of the <b>alternate_issuer_ids.</b></div><div>I'm assuming that for the final VC verifier, the OIDC issuer URL is not meaningful, only the VC issuer (string value or <b>id</b> field).</div><div><br></div><div>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.</div><div><br></div><div>Should I create a BitBucket issue exposing the problem and describing both solutions?</div><div><br></div><div>Thanks,</div><div>Regards,</div><div>Pedro<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 10, 2023 at 11:11 AM David Chadwick via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Pedro</p>
<p>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.</p>
<p>Do you want to raise this as an issue with sourcetree?</p>
<p>Kind regards</p>
<p>David<br>
</p>
<div>On 09/01/2023 17:34, Pedro Felix via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi all,<br>
<br>
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.<br>
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. <br>
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`?<br>
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.<br>
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`.<br>
So,<br>
1) Is it OK to have a mismatch between the metadata
`credential_issuer` and the issued VC `issuer` field?<br>
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?<br>
<br>
Thanks.<br>
Regards,<br>
Pedro</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>