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

[Pedro Felix]

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://credential-issuer.example.com>" *
   }
}

On Tue, Jan 10, 2023 at 4:21 PM Pedro Felix via Openid-specs-ab <
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
> )?
>
> {
>    (...)
>    "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
>>
> _______________________________________________
> 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/15f70d94/attachment-0001.html>