search

decentralized-identity / papers

Notes, ideas, and write-ups from DIF members and collaborators
Apache License 2.0
40 stars 7 forks source link

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

Closed OR13 closed 4 years ago

OR13 commented 5 years ago

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 commented 5 years ago

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

kdenhartog commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.

awoie commented 4 years ago

@OR13 After reading the issue again, I believe we should not include an example for https. The reason why is that it is technically a different protocol. SIOP mandates the openid:// scheme. If you want to use ngrok, you can register your service to handle URL schemes such as openid://. If you want your browser plugin to handle openid://, then this is also possible but in a different way. Does that make sense?

I suggest to close this issue.

OR13 commented 4 years ago

Agreed, simpler is better.