RE: OIDC4VCI JFF PlugFest 2 Questions

Hi Kayode,

David has already answered but just to add a little color.

> How are holders redirected to their wallet from a QR code? In the spec, I see that clients can define a new Issuance Initiation Endpoint (initiate_issuance_endpoint) in its metadata, but it is unclear how and where this is supposed to be defined for a native wallet. Is this supposed to be communicated via the wallet_issuer parameter of an authorization request as defined in section 7.1.3 of the spec? If so, how is this endpoint exposed in a pre-authorized code flow?
-> yes, Issuers and the wallets are expected to pre-agree on the Issuance Initiation Endpoint value using out of band mechanisms, including interop profiles. For the cases when such out of band mechanisms are not available, VCI specification defines a static value `openid-initiate-issuance://` that David's team is using. However, note that there is no guarantee that all wallets supporting VCI also support `openid-initiate-issuance://` and because it is a custom URL scheme, it faces all the usual limitations on mobile OS (which is a broader problem than only for VCI).

> For the pre-authorized code flow, wallets are not expected to hit the authorization endpoint. Since this is the endpoint that shares wallet_issuer with the issuer, how else should the issuer discover this value in this flow? Is that exchange supposed to occur in an unspecified offline process?
-> note that wallet_issuer would work only for the wallets with cloud components that can do dynamic discovery. per https://www.rfc-editor.org/rfc/rfc6749.html#section-3.2.1 wallet can pass `client_id` in the token request, which might be useful if the authorization server already knows metadata tied to certain client_id.

> Am I correct in my interpretation of the issuer parameter of the Issuance Initiation request as the OP issuer URL, at which clients can discover the server metadata (located specifically at /.well-known/openid-configuration, per the original OIDC Core spec), including the new Credential Endpoint (credential_endpoint)?
-> as David said, yes with on-going discussion whether credential endpoint metadata shall be published in a separate file, so would recommend to keep an eye on the outcome - this is probably one the last discussion points before going to the First Implementer's Draft to give implementers IPR protection. Implementer's draft is not a final draft and there are still some open issues, but for some of those we need more implementation experience before deciding on a direction.

Cheers,
Kristina

From: Kayode Ezike <kezike13@gmail.com>
Sent: Monday, September 26, 2022 7:55 AM
To: David Chadwick <david.chadwick@crosswordcybersecurity.com>
Cc: public-vc-edu@w3.org; Kristina Yasuda <Kristina.Yasuda@microsoft.com>; Torsten Lodderstedt <torsten@lodderstedt.net>
Subject: Re: OIDC4VCI JFF PlugFest 2 Questions

You don't often get email from kezike13@gmail.com<mailto:kezike13@gmail.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Thanks for the detailed reply David! Follow-up questions/comments:

  *   For the pre-authorized code flow, wallets are not expected to hit the authorization endpoint. Since this is the endpoint that shares wallet_issuer with the issuer, how else should the issuer discover this value in this flow? Is that exchange supposed to occur in an unspecified offline process?
  *   Could you please share access to the two documents you shared in your response?
  *   Thanks for sharing the credentials for the Identiproof portal, as I have been searching everywhere for that haha!
Cheers,
Kayode

On Mon, Sep 26, 2022 at 6:09 AM David Chadwick <david.chadwick@crosswordcybersecurity.com<mailto:david.chadwick@crosswordcybersecurity.com>> wrote:

p.s. If people want to test the initiate issuance request they can do so by going to this web site that we have created for this purpose (which we demonstrated at the end of the last meeting)

https://idp.research.identiproof.io/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fidp.research.identiproof.io%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C79c55b8c784f42bdc01608da9fcf27e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637998010439215000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=MgJ7UQRPsFF%2FVD%2FWXd%2FAd%2B3PEshBDVh4r6VRzPJ%2BG1o%3D&reserved=0>

Use the username: "user" and the pw: "password" to login. This web site can be used by all three types of wallet: cloud wallets, smart wallets same device flow and smart wallets cross device flow.

Kind regards

David
On 26/09/2022 10:58, David Chadwick wrote:


On 26/09/2022 10:10, Kayode Ezike wrote:
Hi there,

Calling on issuers in the JFF PlugFest 2 cohort and practitioners generally that implement the OIDC4VCI spec as a means of delivering credentials with the following questions:

Hi Kayode



  *   How are holders redirected to their wallet from a QR code? In the spec, I see that clients can define a new Issuance Initiation Endpoint (initiate_issuance_endpoint) in its metadata, but it is unclear how and where this is supposed to be defined for a native wallet. Is this supposed to be communicated via the wallet_issuer parameter of an authorization request as defined in section 7.1.3 of the spec? If so, how is this endpoint exposed in a pre-authorized code flow?

If you read the profile that Spruce and Crossword have written for our interworking tests, all should be revealed. You can find it here

https://drive.google.com/drive/folders/1qHI12GeBhl2s1_bSopDIGpkPdjCE5pMO<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%2F1qHI12GeBhl2s1_bSopDIGpkPdjCE5pMO&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C79c55b8c784f42bdc01608da9fcf27e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637998010439215000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=BrqtDmgNtNIqq6FI7D3xzsPyxhvE9ufA6ZAClWY%2B2Mk%3D&reserved=0>

To answer your question specifically the following deeplink is used

openid-initiate-issuance://?issuer=https%3A%2F%2Foidc4vci.demo.spruceid.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F2foidc4vci.demo.spruceid.com%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C79c55b8c784f42bdc01608da9fcf27e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637998010439215000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=c1MCv2ASvllNj%2FKt7RDu9hmTEDFEVXcEOyEdKL9Knxc%3D&reserved=0> .......

where the issuer parameter points to the issuer and by appending the well known suffix you can find the issuer's metadata. As to what that suffix should be, this is still under debate in the OIDC working group. Spruce and Crossword have published theirs here, and invite other JFF participants to send their details to us and we will add theirs to this table

https://docs.google.com/document/d/e/2PACX-1vQtNazS0EtOO05cR8VM4lCHWtr8KTZRESbiaF3DzpR_JaL3Y540vPjx9d2U4gj7fxMSfi3JRnFQOJKg/pub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2Fe%2F2PACX-1vQtNazS0EtOO05cR8VM4lCHWtr8KTZRESbiaF3DzpR_JaL3Y540vPjx9d2U4gj7fxMSfi3JRnFQOJKg%2Fpub&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C79c55b8c784f42bdc01608da9fcf27e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637998010439215000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=ne%2Bt5LdtaBQ79xyr%2FhfsxPAEySgKVj1reEZmBcYX6mI%3D&reserved=0>



  *   Am I correct in my interpretation of the issuer parameter of the Issuance Initiation request as the OP issuer URL, at which clients can discover the server metadata (located specifically at /.well-known/openid-configuration, per the original OIDC Core spec), including the new Credential Endpoint (credential_endpoint)?

Yes you are correct, but see above

Kind regards

David

Cheers,

Kayode


--
Kayode Ezike | https://ezike.io<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fezike.io%2F&data=05%7C01%7Ckristina.yasuda%40microsoft.com%7C79c55b8c784f42bdc01608da9fcf27e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637998010439215000%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=0lKihvHyS5bMUNb6jXeIxh52fHGeFyWQaOl%2Fp6SqtHI%3D&reserved=0>
MIT | BS 2017 | MEng 2019
Engineer | Writer | Creator