> On May 7, 2019, at 8:02 AM, John Bradley <ve7...@ve7jtb.com> wrote: >
> I believe that for a native app to use mtls via a chrome custom tab or Safari > view controller you need to provision a certificate and private key to the > system keystore. It is not something that can happen dynamically from the > app. > > That in practice is generally done by proprietary EMM (Enterprise Mobility > Management) systems like mobile Iron etc. On iOS you can load a PKCS12 file or use SCEP. You can do so with static policies, but nobody does it that way - they use an EMM system. This really limits things to enterprise usage or value-added features for small businesses that use EMM management integrated into other products like GSuite. > I think there are also some issues with the app using the same key, it may > need to be separately provisioned to the app as well. On iOS, such certificates will be used by the system browser, but will not be used by an embedded web view or otherwise made available to applications. So, code flow and resource access MTLS using a client certificate at the system level is right out, unless some app-specific mechanism to negotiate a client key pair is used. Mobile apps on iOS will need to use ephemeral keys. The client certificate may be used by the system browser to identify the device, so that the user authentication process can also verify that they are accessing from a device that meets corporate policy. So there’s precedent for a MTLS negotiation with the front channel being used for a different, non-PoP purpose. Not to say that enterprises wouldn’t prefer access be tied to a certificate they know was installed on the device and was requested to be non-exportable - there is just no standard way to do that today. Well, I suppose Kerberos. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
