The App Option

[yaronf]

Yaron: the "app" option is problematic, as you already note. The RC may not even know if a given URL will result in an application launching.

Justin: It depends on the nature of app — it could be a single URL like it is in many mobile platforms today but it could also be a bundle of other information that can be used to launch the app. I don’t think we’ll be doing any good by assuming things will continue to be single URLs.

Yaron: and shouldn't the RC include a list of supported applications? (Which would have lovely privacy implications.)

Justin: I think that’s a reasonable dimension and one of the reasons “app” launch should be separate from the “normal” redirect. I brought this up with some implementors in the financial sector a while ago, and with that group at least there wasn’t a lot of desire for that kind of functionality.

I agree that there are some significant privacy implications driving this as well.

Yaron: let's keep it open for discussion, but maybe eventually punt and leave it for future extension(s). I can see why this may look different under different operating systems, for example.

[davidgtonge]

I would be interested to understand more about why the standard redirect option can't work here?

Both iOS and Android have "claimed https" schemes where an https url can be claimed by an app.

[jricher]

There are two reasons for including this as a separate option, and both boil down to not treating web-based interaction the same as app-based interaction:

1. The AS could use different URLs for launching an app vs. interacting at a website.

2. The app launching world (and in particular app2app scenarios) won't always be limited to encoding everything in a URI, and this gives us a chance to define a more robust structure.

If the AS uses a single URI for both launching the app and interacting at a webpage, it can still do that with the basic redirect option, and this functionality doesn't apply.

[davidgtonge]

I would suggest that this be an extension then.

Most of the time in my experience, the versatility of having the same uri work for web and app, outweighs the negatives. For example the client and AS (sorry old terminology) may both offer both a web and app. Even if the client is always an app, it may not know whether the user has an app for the AS installed.

[jricher]

Thanks for the feedback. The group hasn't fully settled on what is going to stay in the core document vs. what's going to be an extension, and what the relative timelines and targets for any extensions would be.

[yaronf]

These are typically two separate decisions. The group decides on what goes into the core document. Some time later, someone who has a good use case drives work on the extension. An extension may be a WG document or not, depending on WG interest.

[jricher]

The app option is a simple start mode with clear semantics, so there's not a compelling argument to remove it from the core or push to an extension.