feat: support openid invitations and deeplinking improvements #97
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for deeplinks and invitation urls for OpenID4VC created by Paradym.
It also expanded the parsing logic to be as flexible as possible. That means that:
credential_offer
orcredential_offer_uri
query params, or any of the open id issuance schemes are used in a deeplink or a QR data url we scan we assume it's an openid credential offerrequest
orrequest_uri
query params, or an of the open id verification schemes are used in a deeplink or a QR data url we scan we assume it's an openid presentation requestoobUrl
,oob
,c_i
,d_m
query params or thedidcomm
schema is used in a deeplink or a qr data url we scan we assume it's didcomm invitationIf it can't be detected from the url alone we fetch the URL and then do anoter set of checks to see what type of invitation it is.
I also made the DIDcomm flow more similar to the openid flow, not showing the QR scanning too long, but redirecting to a loading screen. This also makes the deeplink flow better as it now doesn't do a lot of processing in the background which you can't see
I also added a general umatched route and just render
null
here. The deeplink handler resets the routing state now on every deeplink so we always route to the correct state (with the downside that you lose your navigation state when you deeplink into an active app, but with the three screen we have that's really a non-issue at the moment IMO). This means that ANY deeplink url (with random paths) now works, and if it isn't a deeplink we support it will just only reset your navigation state (so you'll be on the home screen)..See attached videos for example flows.
RPReplay_Final1712507731.MP4
RPReplay_Final1712507647.MP4
RPReplay_Final1712507578.MP4