W3C home > Mailing lists > Public > public-webauthn@w3.org > September 2019

Re: [webauthn] Specify if clients are expected to follow redirects for icon URLs (#1285)

From: David Waite via GitHub <sysbot+gh@w3.org>
Date: Tue, 03 Sep 2019 18:24:51 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-527580095-1567535090-sysbot+gh@w3.org>
> On a practical note do we have the size etc of the icons sufficiently defined so that a platform could display them? This may be a bit like the authenticator icon in meta-data, something that seems like a good idea, but is never used in practice

Thats my concern. We also have two icons:

1. The RP entity icon, which likely is the same for all RP registrations. It isn't useful for choosing a credential to use, but may be useful if you are managing the credentials on an authenticator.

2. The user entity icon, which is likely different for each registration. It might be useful for choosing a credential to use, but will likely only contain a usable value if the RP maintains profile information including a photo or avatar. It also must be user-differentiated, so fundamentally must leak information on loading.

If desired, the RP icon would have a good shot of being changed to be widely usable. For example, we could reference an image source set via .well-known of the RP domain, and have clients fetch that without session state. Of course, a well-known lookup also technically no longer needs the URL field.

We don't have infrastructure to use the user icon ad-hoc (such as an intermediate, anonymizing cache). So the user icon is only really displayable if previously cached by a registration or authentication action, loaded by user action, etc.  We still would have the problem that not all RPs have a usable picture for this, or guidance on how it will be displayed.

-- 
GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1285#issuecomment-527580095 using your GitHub account
Received on Tuesday, 3 September 2019 18:24:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:07 UTC