Register openid:// URL scheme with IANA

[awoie]

On iOS the behaviour is undefined when multiple apps register a handler for the same custom URL scheme. This behaviour is different if the URL scheme is registered with IANA. We need to register openid:// as a well-known URL scheme to get better support on iOS.

[kdenhartog]

@timcappalli or @selfissued are either of you able to comment on the status of this issue?

[timcappalli]

We're still discussing the potential impact of this (ex: two apps registering openid:// and/or platforms allowing it to be registered).

[selfissued]

I filed this OpenID Connect issue to track doing this https://bitbucket.org/openid/connect/issues/1173/register-openid-uri-scheme

[awoie]

@timcappalli please share any updates of your investigations. My understanding is that on Android, the user will be able to choose the app and on iOS the behaviour is undefined. The undefined behaviour was the reason why we wanted to get openid:// registered as we expected that this would change that behaviour on iOS. Very similar to what happens if the user had multiple mail apps installed.

[timcappalli]

@awoie we're concerned with multiple parties using openid:// on the same device. While the mail situation is similar, it is still a fairly specific type/action whereas openid:// could be any OIDC flow.

Scenario: X company starts using openid:// to invoke a token broker app for SSO. Y company uses openid:// for their DID wallet. If the user is given a choice, they're not going to know what to do. That assumes the user is given a choice (which I don't think is possible on iOS).

The other question is what criteria does Apple evaluate to allow an app to register an app handler for a scheme they do not own (aka, not their app name).

[awoie]

@timcappalli SIOP mandates openid://. anything else such as wallet:// would not result in SIOP backwards compatibility. is openid:// overloaded and being used by anything other than SIOP?

[timcappalli]

Linked OIDF work item: https://bitbucket.org/openid/connect/issues/1112/register-openid-to-the-well-known-uri

[timcappalli]

@timcappalli SIOP mandates openid://. anything else such as wallet:// would not result in SIOP backwards compatibility. is openid:// overloaded and being used by anything other than SIOP?

So there's really two separate concerns.

1. openid:// is very "generic" in a sense that it is not specific, from a naming perspective, to a SIOP flow. So for example, should it really be 'oidcsiop://' ? The thinking here is that someone may decide to use openid:// for vanilla OIDC flows with a token broker app. I know we can't prevent everyone from misusing, but if we want to propose a different scheme, now seems like the time

2. The second one is the multiple wallet problem which I don't necessarily have a proposed solution for. There is a high probability that the average user will have multiple wallets on their device. This is a major concern for user experience. iOS does not guarantee which app will open a scheme. Android has a picker mechanism, but that still relies on the user to make a decision. And while this is not a specific "spec problem", I think this needs significant discussion.

[awoie]

I agree with @timcappalli that these are two separate concerns.

Re 1. if we believe that openid:// is not the right URL schema then we would have to change the OIDC spec, or we won't be interoperable with it anymore. I do agree that a dedicated schema like wallet:// would be beneficial. If OIDC interop is not a requirement anymore, then we could simplify the whole flow as the OIDC interop part introduced a lot of overhead.

Re 2. yes, that is also my understanding. While there is always the option to simply scan the QR Code directly in the desired wallet app, you would still have the issue with deep linking. That issue was addressed in the UX considerations section. Our hope was that by registering the oidc:// scheme in IANA, iOS' behaviour might change.

[kdenhartog]

As a side note regarding 2, we may be getting closer with iOS 14 now supporting changing the default browser and default mail client. I'd suspect Apple is getting closer to support for this, but probably won't be there yet on release.