CTAP allows that authenticators can use a data URL for the icon
Note that icon values used with authenticators can employ [[!RFC 2397]] "data" URLs so that the image data is passed by value, rather than by reference. This can enable authenticators with a display but no Internet connection to display icons.
There's no mention of that anywhere in the WebAuthn spec, nor does it mention if the browser is expected to resolve a URL to a data URL on behalf of the authenticator. We should probably add some processing rules for icons.
I don't think it's reasonable to expect WebAuthn to retrieve icon URLs and create data URL values for authenticators. Among other problems, this will significantly blow up the message size.
@agl notes on webauthn call today:
two parts of the issue:
@emlun -- concerned that icon-holding data: url will be large, leave it to the client to display...
@agl: limited authnrs will want the client to handle this, more capable authnrs cound deal with it themselves... perhaps we need two fields, one for URL and one for data
folks note that the message gets large when the URL is data url.
@emlun - ought to point out this "can be a data: URL" and leave it at that...
@selfissued agrees
@akshayku agrees, thinks incomplete soln, but good enuff for now
@apowers313 notes CTAP says it can be either data: or other (http) url but does not address it further.
@selfissued notes that what is actionable now is to just state this can be a data: url as @emlun suggests... and point to the RFC
Per the 6-Jun-18 call, @apowers313 will create a PR pointing out that the URL can be a data URL.
@selfissued asked for “Adam” and it was me who answered, rather than @apowers313. So I did #937 for part of this bug.
As noted in https://github.com/w3c/webauthn/issues/930#issuecomment-395150445, there are two parts to this issue, of which we decided to do (1) but not (2). If someone wants to do (2) for level 2, they're welcome to open a new issue for that.
Most helpful comment
@selfissued asked for “Adam” and it was me who answered, rather than @apowers313. So I did #937 for part of this bug.