Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SIOP] openid:// alternatives for agents #19

Open
OR13 opened this issue Aug 5, 2019 · 6 comments

Comments

@OR13
Copy link

commented Aug 5, 2019

Is it the case that if we replace openid:// with https:// this same auth flow can be used by an agent?

For example, if I run an Identity Wallet on my laptop, and expose it via ngrok, should I not be able to complete the auth flow?

using ngrok is typical for testing OAuth flows that require an https callback, as you can read about here: https://www.chrisjmendez.com/2018/04/16/using-ngrok-with-facebook-oauth-login/

@OR13

This comment has been minimized.

Copy link
Author

commented Aug 5, 2019

@TelegramSam @kdenhartog Do you guys know if this is supported by Aries?

@kdenhartog

This comment has been minimized.

Copy link

commented Aug 6, 2019

Yes this should be possible in either situation I believe. We've been looking at operating DIDComm using didcomm:// just recently as well. @tplooker just opened an issue that talks about a very similar topic.

I believe that the main tradeoff that we're considering is how to register apps to handle specific URLs which is why we were exploring this. When we used https:// we ran into weird non-deterministic issues around handling the did exchange protocol while also trying to support onboarding via deeplinks.

Is openid:// being used in similar ways?

@awoie awoie added the did-authn-siop label Aug 6, 2019

@awoie

This comment has been minimized.

Copy link
Member

commented Aug 6, 2019

Yes, there is no difference in using openid:// or didcomm://. https:// is of course complicated. For example, on iOS, you have to host a file under the defined domain that was signed with the key associated with your provisioning profile. That is not a viable approach if you want to have one https: URL that can be handled by different Identity Wallet providers. You don't want to share the private key.

Once you exchanged the DID Document, you could always look up an openid service endpoint in the DID Document and start the OIDC Discovery protocol from there. The problem is how to exchange the DID Document. That is what we are trying to solve with SIOP.

If you had the OP URL, you would be free to use any OIDC flow to obtain the id_token.

@OR13

This comment has been minimized.

Copy link
Author

commented Aug 7, 2019

This is extremely good news, I think we need to add examples for https://, the iOS issue is interesting, I don't fully understand what the issue is, can you provide more detail @awoie

@awoie

This comment has been minimized.

Copy link
Member

commented Aug 8, 2019

I have to correct me. The file does not have to be signed, but in order to enable "universal links" you have to place an "Apple App Site Association File" under a .well-known URL. I'm not sure if the association file can have multiple mappings for the same domain+path.

@OR13

This comment has been minimized.

Copy link
Author

commented Aug 8, 2019

That seems fine to me, this appears to be for mobile apps that want to rely on deeplinks with a web server agent. I don't see any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.