FedCM nonce Parameter Deprecation Specification - #762
Conversation
TallTed
left a comment
There was a problem hiding this comment.
Markup tweaks for clarity
npm1
left a comment
There was a problem hiding this comment.
Thanks for the writeup! A lot of this seems written from the Chromium perspective, such as the plan to mitigate the backwards incompatible change (since only Chromium has shipped FedCM). I suppose it doesn't harm to document the plan, but this should probably be made more concise as the proposed spec change here is very simple. In fact, I would have probably directly sent a PR to modify the spec, which this PR is not doing.
| - Show a deprecation warning in developer tools when the top-level parameter is used | ||
|
|
||
| 2. After the transition period, the browser: | ||
| - MAY reject requests that use the top-level `nonce` parameter |
There was a problem hiding this comment.
I don't think this is what would happen. Parameters that are not members of the dict are just ignored.
| - SHOULD continue to show deprecation warnings until the parameter is fully removed | ||
|
|
||
| 3. When constructing token requests to the IdP: | ||
| - Use the `nonce` from `params` if available |
There was a problem hiding this comment.
This doesn't make sense. Params is arbitrary, so you can always define nonce on it.
|
|
||
| ### 5.1. Browser Implementation | ||
|
|
||
| The browser should modify the token request generation code to extract the `nonce` from the `params` object when available: |
There was a problem hiding this comment.
| The browser should modify the token request generation code to extract the `nonce` from the `params` object when available: | |
| The browser should modify the token request generation code to extract the `nonce` from the `params` object when available. |
There was a problem hiding this comment.
But actually I think this is just wrong, the browser would not need to modify anything since params is already sent to the IDP. The difficult part is removing support to send the nonce from outside of params.
|
|
||
| The IdP implementation remains unchanged as the browser will continue to pass the nonce parameter to the token endpoint in the same format. | ||
|
|
||
| ## 7. Migration Path |
There was a problem hiding this comment.
This seems repetitive with a previous section.
There was a problem hiding this comment.
Although the content may appear repetitive, it is presented under distinct headers/sections. If you feel the repetition should be minimized, please let me know which section you'd prefer to remove.
|
My understanding of the "params" property was that its content is deliberately arbitrary to allow protocols building on FedCM like FedCM for OAuth by aaronpk to define it. Moving the nonce parameter into "params" (or even parsing "params" in the browser implementation to extract the nonce) would change that. |
|
If i remember the discussions correctly, the intent was to deprecate the |
| ### 4.1. Browser Behavior | ||
|
|
||
| 1. During a transition period, the browser MUST: | ||
| - First, check for `nonce` in the `params` object |
There was a problem hiding this comment.
This should not be needed, right? params should be passed where nonce is passed. No need to 'check' for it
|
|
||
| ### Phase 2: Elevate Warning to Error | ||
|
|
||
| - Warning is upgraded to an error-level message |
There was a problem hiding this comment.
Generally, having a non-existent type in a dict does not lead to an error, so should this actually be an error?
| 3. When constructing token requests to the IdP: | ||
| - Use the `nonce` from `params` if available | ||
| - Use the top-level `nonce` as fallback during transition | ||
| - Pass the `nonce` value to the assertion endpoint as before |
There was a problem hiding this comment.
The purpose of the change is that the browser does not need to know about nonce at all. So, an RP would pass the nonce to the IDP using params, it would be sent like any other param, and the browser gets out of sending the toplevel nonce parameter that it does today.
|
Discussed on the July 29 call. |
|
Closing this since the spec change is done. |
The Federated Credential Management (FedCM) API currently allows Identity Providers (IdPs) to specify a
nonceparameter as a top-level field in the provider configuration object. This specification proposes deprecating this top-level parameter and moving it to theparamsobject, which is the intended location for all IdP-specific parameters. This change will improve API consistency while maintaining backward compatibility during a transition period.