search

eu-digital-identity-wallet / eudi-lib-ios-wallet-kit

This repository contains the EUDI Wallet Kit library for iOS. The library is a part of the EUDI Wallet Reference Implementation project.
https://eu-digital-identity-wallet.github.io/eudi-lib-ios-wallet-kit/
Apache License 2.0
11 stars 14 forks source link

Pushed Authorization Request and request_uri #83

Closed icarboneaq closed 3 weeks ago

icarboneaq commented 4 months ago

Attempting to use EUDI Wallet Kit/Core to connect to an issuer that is using Microsoft as an identity provider. Wallet-Core seems to work fine, but Wallet-Kit fails with a ValidationError if no pushed_authorization_request_endpoint is provided. Further to that, Wallet-Kit passes a 'request_uri' to the auth endpoint regardless of whether or not 'request_uri_parameter_supported' is true or false. This causes the Microsoft identity provider to fail the login as it doesn't support 'request_uri'.

Is PAR intended to be required? The OpendID4VCI draft 13 spec lists it as recommended, but not required.

dtsiflit commented 2 months ago

@icarboneaq have you tried this configuration?

wallet.openID4VciConfig = .init(
  clientId: configLogic.vciConfig.clientId,
  authFlowRedirectionURI: configLogic.vciConfig.redirectUri,
  usePAR: false
)

If you set usePAR to false it won't use it.

icarboneaq commented 3 weeks ago

Thanks for the response! It does in fact work if I set this. The thing is, I want to be able to potentially configure the wallet to work with different identity providers simultaneously. Is this the kind of thing where I need to manually hit the openid metadata first to determine whether PAR is supported and then initialize the wallet? If I switch to a different IP, would I need to re-init the wallet? I just want to double check as Wallet Core seems to behave differently. Thanks for your help!

dtsiflit commented 3 weeks ago

Thanks so much @icarboneaq glad to hear that!

To address your questions:

Checking the metadata before deciding on using PAR is a valid approach. Additionally, a workaround is being developed that will allow clients to determine a server’s capabilities in advance. I’m not sure yet when this will be available, but I’ll be sure to update you in a comment here as soon as I know more.

If you switch to a different IP, reinitializing the wallet may be a feasible solution. This would require that the new IP recognizes the client (meaning the client has already been registered, and the IP has an assigned identifier) and that the wallet is configured to use this identifier for the registered client.

I hope this helps!