Re: OIDC4VCI JFF PlugFest 2 Questions

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> 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/
>
> 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
>
> To answer your question specifically the following deeplink is used
>
> openid-initiate-issuance://?issuer=https%3A%2F%
> 2Foidc4vci.demo.spruceid.com .......
>
> 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
>
>
>
>    - 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
MIT | BS 2017 | MEng 2019
Engineer | Writer | Creator