- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Mon, 02 Mar 2020 04:42:29 +0000
- To: public-webauthn@w3.org
I'm starting to think that the _runtime connection only to the PISP and not the bank_ argument for justifying the approach described in this issue is flawed. If a browser were to have a discovery mechanism to determine if PISP was allowed to call _navigator.credentials.get_ using the RPID of the bank, then almost certainly that discovery mechanism needs to be hosted at some well-known URL owned by the bank (i.e. a page that's part of the site identified by the RPID). That is what is done for Android and assetlinks.json today as well. The retrieval of the discovery document becomes part of the runtime flow and whilst potentially read-only and cacheable does that really make it more highly available than assuming the browser can contact the bank for real-time loading of a cross-origin iframe? I also have some concerns over the idea that in this scenario the bank doesn't get to generate any part of the challenge, yet is responsible for verifying the assertion. This means building unsolicited assertion semantics into the protocol for freshness and nonce protection. Whilst that may eventually be a good thing and offer similar features to the time-tested unsolicited SAML-browser-POST SSO semantics, is this something that WebAuthn wants to define? -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1372#issuecomment-593215960 using your GitHub account
Received on Monday, 2 March 2020 04:42:30 UTC