<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Advanced on passkeys.dev</title><link>https://52c12ba8.passkeys-dev.pages.dev/docs/advanced/</link><description>Recent content in Advanced on passkeys.dev</description><generator>Hugo</generator><language>en</language><atom:link href="https://52c12ba8.passkeys-dev.pages.dev/docs/advanced/index.xml" rel="self" type="application/rss+xml"/><item><title>Client Hints</title><link>https://52c12ba8.passkeys-dev.pages.dev/docs/advanced/client-hints/</link><pubDate>Wed, 24 Sep 2025 05:07:38 +0000</pubDate><guid>https://52c12ba8.passkeys-dev.pages.dev/docs/advanced/client-hints/</guid><description>&lt;h2 id="overview" class="heading ">Overview&lt;a href="#overview" aria-labelledby="overview">








&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 576 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>When creating a passkey, WebAuthn Clients display a credential manager selection screen asking users to choose where to store their new passkey. The selector typically defaults to local credential managers because they offer immediate availability and support for synced passkeys, the default credential type in unmanaged, consumer contexts.&lt;/p>
&lt;p>During a sign in flow, the WebAuthn Client will do its best to help the user select a passkey which is immediately available, and fall back to an external authenticator selection screen. This typically shows an option for 
 









 
 
 
 


 
 

 
 

 
 &lt;a href="https://52c12ba8.passkeys-dev.pages.dev/docs/reference/terms#cross-device-authentication-cda">FIDO Cross-Device Authentication&lt;/a> and security keys. In environments where only security keys are allowed, having additional options such as displaying a QR code for cross-device authentication flows can confuse users and lead to unnecessary support costs.&lt;/p></description></item><item><title>Related Origin Requests</title><link>https://52c12ba8.passkeys-dev.pages.dev/docs/advanced/related-origins/</link><pubDate>Thu, 22 Aug 2024 15:20:51 +0000</pubDate><guid>https://52c12ba8.passkeys-dev.pages.dev/docs/advanced/related-origins/</guid><description>&lt;h2 id="use-cases" class="heading ">Use Cases&lt;a href="#use-cases" aria-labelledby="use-cases">








&lt;!-- &lt;i class="fas fa-link anchor">&lt;/i> -->
 &lt;svg class="svg-inline--fa fas fa-link anchor" fill="currentColor" aria-hidden="true" role="img" viewBox="0 0 576 512">&lt;use href="#fas-link">&lt;/use>&lt;/svg>&amp;nbsp;
 &lt;/a>
&lt;/h2>
&lt;p>The two use cases for Related Origin Requests (ROR) are deployments which use different country code top-level domains (ccTLD) across the world, and deployments where different branding is used for different services.&lt;/p>
&lt;p>To address these use cases, it is recommended to leverage industry-standard federation protocols such as 
 









 


 &lt;a href="https://openid.net/specs/openid-connect-core-1_0.html" target="_blank" rel="noopener noreferrer nofollow">OpenID Connect&lt;/a>. This approach facilitates a centralized login experience, by using a dedicated login page (e.g., login.example.com) that serves as the authentication point for all origins and services.&lt;/p></description></item></channel></rss>