-
Notifications
You must be signed in to change notification settings - Fork 15
Add isProtocolSupportedByClient static method #221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this, I think it probably is important and valuable given WebKit's plans to not support some popular protocols. Should we perhaps define this to call an internal function, which then we also call from the main processing parts of the spec and return a well-defined error for when the result is 'false'? @marcoscaceres @mohamedamir WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor text changes for clarity
Co-authored-by: Matthew Miller <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a good compromise across verifiers, browsers, and platforms 🤔
Hey all, please see #168 ... I proposed a different way of doing this there that is, IMO, more developer friendly and avoid the "support" question... that the browser recognizes the protocol string does not imply "support" for it. I suggest we refactor this pull request to align more fully with #168 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see #168
Co-authored-by: Christian Bormann <[email protected]>
Is this intended to only reveal information on what the browser version supports passing through and specifically not to reveal any details of what wallets are available, what the user has configured, what credentials they have, whether they have another device that supports credentials, etc.? (I know I raise this question every time it comes up, but we haven't written down the answer, so I keep asking.) If so, we should add normative requirements that indicate that. |
Essentially: "can you pass a request with this protocol to the next component" There is no possible way for it to reveal any details about wallets or credentials. It just returns a boolean given a protocol identifier. |
Browsers could modify the response based on some knowledge of wallet availability or configuration. I think we should just specify that the UA shouldn't use that kind of knowledge for a customized value, they should only describe browser-level support without user/device/app/wallet configuration detail. |
Not sure I follow. The browser is the only party handling this request and response. |
As in, a browser vendor trying to implement this section could try to use their knowledge of system/app/wallet/user-configuration properties to modify the return value, and I think this API should tell the browser vendor implementer not to do that. |
Gotcha. I'm not sure how we write something like that given each browser has their own method of determining what the response should be. Do you have some suggested text? |
I can try to propose something (tomorrow, likely) that would set some SHOULD NOT/MUST NOT conditions to try to capture what I think is the agreement. |
This method does not convey protocol support in the underlying platform | ||
or credential provider. | ||
</p> | ||
<p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<p> | |
<p> | |
User agents SHOULD NOT vary the response value based on any information about availability of hardware, presence or configuration of software, wallets or credentials, or user configuration or preferences. If the response value varied, the user agent would introduce risks both of fingerprinting and of silently revealing other details about user behavior or configuration. The response value SHOULD vary only by user agent major version and indicate whether the browser supports distributing requests with that protocol to underlying platform or provider. | |
</p> | |
<p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a starting point proposed text for trying to capture the idea that this is just a convenience method indicating browser version support, rather than details to the site about what the user has configured.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds great @npdoty. thanks!
Closes #219
The following tasks have been completed:
Implementation commitment:
Documentation and checks
Preview | Diff