Persistent session secrets, SSO, and iOS

[whitehatguy]

I've been examining how to apply the principles set forth in section 7.2 Reauthentication for a set of independent native applications on iOS and seem to have run into a snag related to secret persistence. 7.2 indicates that session secrets should not persist:

Session secrets SHALL be non-persistent. That is, they SHALL NOT be retained across a restart of the associated application or a reboot of the host device.

On iOS, Apple promotes the use of a non-ephemeral ASWebAuthenticationSession to achieve single sign-on operations between a web site and a relying party native application. Applications that attempt to directly interact with Safari for purposes of SSO are flagged during Apple's application review process.

For ASWebAuthenticationSession, Apple specifically notes the following:

When not using an ephemeral session, all cookies except session cookies are available to the browser.

Through development, I have confirmed this to be true - only persistent cookies are available to browser instances invoked through ASWebAuthenticationSession.

Given this, it does not appear to be possible to implement single sign-on for iOS native applications while still complying with 800-63 guidance.

Secondarily, any identity provider that allows for single factor reauthentication pursuant to AAL2 would be unable to do so, as it would be unable to access a non-persistent session secret in ASWebAuthenticationSession (session cookies do not persist across multiple invocations of ASWebAuthenticationSession.)

I'm opening this discussion thread for three reasons:

1. I hope to raise visibility to this issue to a larger segment of the identity community, as I do not feel this to be a well-understood problem. Perhaps others may have already come to some other solution?
2. I'm interested in learning more about whether a specific threat model was assumed related to this technical requirement (for example, is it assumed that a persistent session secret would not be protected by device-level TPM encryption associated with a user account?)
3. I'm interested in the author's opinions as to whether "Device Identification" as described in section 7.1.3. would be some form of alternative for addressing this concern on the iOS platform. For example, if a persistent secret associated with the endpoint device such as a public/private key exposed via WebCrypto API or an mTLS certificate were used to bind the session, does that address the concern? Does 7.1.3. assume that device identification is somehow tied to the subject of such a session?