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

Wed Jan 11 16:28:08 UTC 2023

Issue created -
https://bitbucket.org/openid/connect/issues/1778/openid4vci-relation-between-the-metadatas

On Wed, Jan 11, 2023 at 12:24 PM David Chadwick via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Hi Pedro
> On 10/01/2023 16:20, Pedro Felix via Openid-specs-ab 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>" *
>    }
> }
>
> Yes correct. This is the example that the JFF Plugfest is using
>
> "issuer": {
>     "type": "Profile",
>     "id": "did:key:z6MkrHKzgsahxBLyNAbLQyB1pcWNYC9GmywiWPgkrvntAZcj",
>     "name": "Jobs for the Future (JFF)",
>     "url": "https://www.jff.org/" <https://www.jff.org/>,
>     "image": "https://kayaelle.github.io/vc-ed/plugfest-1-2022/images/JFF_LogoLockup.png" <https://kayaelle.github.io/vc-ed/plugfest-1-2022/images/JFF_LogoLockup.png>
>   },
>
>
> - "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)?
>
> Yes, this is what I meant by standardising the name of this property. In
> the JFF example it would be "issuer.url"
>
>
> Did I understood it correctly?
>
> Yes.
>
> 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.*
>
> *or issuer.id <http://issuer.id> *if its an issuer object
>
>
> 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.
>
> A related issue is "how did the verifier actually get the public key of
> the issuer, and how does it know it is the correct public key?" This is the
> real issue that needs to be resolved in my opinion. One way can be to take
> the issuer URL and then read the issuer's metadata from its well known URL,
> which will contain the jwks-uri. In this case identifying the issuer by a
> URL is perfectly acceptable and no did is needed.
>
>
>
> Should I create a BitBucket issue exposing the problem and describing both
> solutions?
>
> Yes please. It will allow the issue to be raised, logged, discussed and
> resolved.
>
> Kind regards
>
> David
>
>
> 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 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/20230111/88b2c0aa/attachment-0001.html>