- From: Eric Stern via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Oct 2024 19:03:01 +0000
- To: public-webauthn@w3.org
Agreed @arianvp. HTTP semantics aside, there are countless situations where the proposal might not work for a given RP - including political/bureaucratic, non-technical reasons - and I'd be disappointed if only a subset could benefit from the improvements this change could yield. Any application today that a) DOES[^1] need any kind of authn to get their challenge and b) uses anything other than cookies to perform that authn (e.g. Authorization header) couldn't use this as proposed. > In the WAWG discussion at TPAC yesterday the challenge URL was understood to be a better pattern for mobile use cases as well, so that whether you're in a browser or a native app an RP could allow for parallelizable credential discovery and challenge requesting to significantly improve some at-scale passkey auth scenarios @MasterKale are you or others able to provide a bit more background here, especially for those of us that were not at TPAC? From the rest of your comment, I'm interpreting "better pattern" to mean "better pattern than `challengeCallback: () => Promise<BufferSource>`" rather than "better pattern than the status quo of inlined `BufferSource`", so please correct me if I'm misinterpreting! I'd especially like help understanding how this impacts native apps at all, since they have their own platform-native APIs (e.g. the `ASAuthorization` family in Apple's ecosystem) and are, at most, only really impacted by the definition of the signing process. Implementation aside, I think it would also be worth adding another value into `getClientCapabilities()` to indicate the availability of wherever this lands. If possible, I think it's also worth adjusting the "fetch behavior" section to replace the create/get split with conditional/non-conditional mediation. This would allow conditional create to benefit in the same ways (reduced data loading when not needed, being able to have short challenge TTLs, etc) as conditional get. [^1]: this isn't commentary on whether that _should_ be the case, as has already been discussed at length in the thread. -- GitHub Notification of comment by Firehed Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2152#issuecomment-2403168651 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 October 2024 19:03:02 UTC