[Openid-specs-native-apps] Fwd: Web Browser news from WWDC

[David Waite]

> On Jun 15, 2015, at 12:54 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:
> 

> What I don’t know is what happens if two apps claim the same URI etc.

There is a manifest at the root of the website, mapping bundle id’s to a set of paths or wildcard prefixes. You could register two apps to have the same path, and the behavior is most likely undefined if both are installed. 

> The other thing to consider is that with Fido 2.0 it will have a JS API and may work just as well from JS browser tab as from a native app.

You can manifest custom fido integration logic and javascript APIs via the integrated web views/controls, but a system browser tab will likely require native integration with the platform for fido to work.

> There is also a attestation API on Android, that a calling app could possibly use to prove it’s bundle id etc on the device using the browser flow.
> I don’t yet know if Apple will have something similar.

Sounds like they are trying to give less information about other apps, not more. But if the website is the one claiming a bundle id should be used for certain URLs, do you really need independent verification?

> So as a thought experiment,  what if doing NAPPS from the app point of view is just the OAuth code + PKCE or OAuth + ACDC plus a possible app attestation.
> 
> SaaS apps would still need discovery/MDM to know what enterprise to talk to, but basically any enterprise app doing code + pkce would just work,  and can transparently be redirected to a native token agent if desired.
> 
> Or I suppose we could decide that if we can get 99% of what we want without a native token agent.  If that is the case then perhaps some things could be simplified.

If all the pieces actually work together, the client doesn’t even need to know about token agents:

1. the client requests OAuth by attempting to open a new safari/chrome tab in-app with the proper OP URL
2. the system sees that URL should actually be displayed via an installed app, the token agent
3. the system displays the token agent app instead of the browser tab. This appears to be done via NSUserActivity
4. the token agent authenticates the user through some undefined process that yields a code
5. the token agent tells the system to open the redirect URI in the system browser.
6. the system sees the URL should be displayed via an installed app, the native client
7. the native client exchanges the code on the URL for an access token and a refresh token

-DW