-
Notifications
You must be signed in to change notification settings - Fork 72
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
Add the IDP sign-in status API to the spec #436
Changes from 1 commit
e2f48cc
8304968
465c717
896e95d
07eb407
8948f99
f19c445
663f421
090262d
d682586
9557220
0c154cb
d932e3f
f128898
71083c8
3fbe365
238fdf4
13ca4f7
4db1336
0c77ac9
afe7360
ddb3f24
2098134
5b091a0
6a38c4b
654908f
652b436
fb02431
d70fa1f
620848c
b6b9be3
436ee85
3c8eb4a
04e7156
99147b3
e7ab849
1fbab48
7f6eef5
0f0c4fe
e80e54a
bf30c3d
49fe2ad
2133a0b
d28201f
0d55b05
60cdb08
48e4d1a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -312,8 +312,9 @@ map</dfn>, an initially empty [=map=]. The [=map/keys=] in this map are | |
and "<dfn><code>signed-out</code></dfn>" | ||
|
||
The user agent checks all page and subresource loads for an HTTP response | ||
[[RFC9110#header.fields|header]] named `IdP-SignIn-Status`, whose value | ||
is parsed at HTTP [[RFC9110#parameter|Parameter]]s. | ||
[[RFC9110#header.fields|header]] named | ||
<dfn><code>IdP-SignIn-Status</code></dfn>, whose value is parsed at HTTP | ||
[[RFC9110#parameter|Parameter]]s. | ||
If that header exists and the first parameter has a name of `action`, | ||
the user agent must process it as follows: | ||
|
||
cbiesinger marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
@@ -330,8 +331,26 @@ the user agent must process it as follows: | |
Issue: Should the header checking be integrated into the fetch spec instead, | ||
since it affects all resources? | ||
|
||
User agents must also clear the [=IDP Sign-in Status map=] when the user clears | ||
cookies or stored site data. | ||
User agents must also clear the [=IDP Sign-in Status map=] data when: | ||
cbiesinger marked this conversation as resolved.
Show resolved
Hide resolved
|
||
: the user clears all cookies or site settings data | ||
:: The user agent must clear the entire map | ||
cbiesinger marked this conversation as resolved.
Show resolved
Hide resolved
|
||
: the user clears cookies or site data for a specific origin | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think what you mean here is that the user clears all cookies or site data which is accessible by a specific origin? That is, there is no way the user is still signed in to that origin. I'm not sure this is clear from the text There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the intent was: Tried to clarify this... |
||
:: The user agent must remote all entries that would be affected | ||
by the deleted cookies. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the part that I think needs to be clearer. It might even need some more thought. When you clear state for an RP, you probably just forget those identities (and the associated IdPs) that were used. However, when you clear state for an IdP, there will be a bunch of RPs that have received identity information from the IdP. I see a two options, each with drawbacks.
Note that in the first case, if you allow for the possibility that each RP might also have established links to other IdPs, then you might also need to clear state for any of those RPs as well. It's a connected graph and the only way to make clean break is to burn out all the links. Of course, that might be even more surprising. At some point though, you need to recognize that this sort of purging needs to consider all forms of linkability, so you might want to stop before the only action you permit involves clearing all browser state. I don't think that there is an easy cut to make between these two. I can see how different browsers might choose to take different approaches on the basis that they take different perspectives on how to empower their users. One option favours user control over privacy, the other favours convenience. For a specification, we generally try to document the considerations carefully and clearly, then leave these decisions to implementations. It is OK to do that because there are no guarantees on retention of site-level state, just as there are no firm rules about how private information is managed, so each browser gets to choose their own approach. Note that I'm talking about a problem with broader scope than your change. You're the lucky one to have to contend with this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, the more I think on this, the more I realize that this cuts in both directions. The only thing that might make the RP clearing case simpler is that we have a different perception of the IdP role in this process.
For the latter, we already rely fairly heavily on the user making a trust decision with respect to the information the IdP might have about them. That is not a symmetric relationship with the RP. We don't assume that the user trusts the RP in the same way. (Lots of stuff to write...) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have elaborated on the line you commented on to describe the intent I had. As you say, I think a lot of what you brought up here is only tangentially related to the IDP signin status API (this PR) and applies to FedCM in general. However, the way I think about it is that the connection between RP and IDP is more akin to a permission. Permissions in general don't get deleted when the user clears cookies... To be honest, I think it would be surprising to users if deleting (e.g.) google.com cookies logged them out of (e.g.) Pinterest and Tripit? I think I'm going to file a github issue to discuss all this, because it should probably involve not just you and me :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I filed #493 |
||
|
||
Note: For example, domain cookies may affect subdomains of | ||
the deleted origin. | ||
: if the user agent allows deleting individual cookies | ||
:: the behavior is user agent-defined. | ||
|
||
Note: The user agent may want to reset the state to undefined, | ||
cbiesinger marked this conversation as resolved.
Show resolved
Hide resolved
|
||
since is impossible to know whether this cookie affects | ||
authorization state. | ||
|
||
Note: Website-initiated cookie changes should not affect this map. When | ||
IDP sign-in state changes, it should send an explicit | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think that this is true: https://w3c.github.io/webappsec-clear-site-data/ There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have added a section on interactions with Clear-Site-Data. |
||
[=IDP-SignIn-Status=]. | ||
RP state should not affect this map since it only reflects IDP state. | ||
|
||
IDPs can also use a JavaScript API to update the stored sign-in status: | ||
|
||
|
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.
Presumably this needs to be parsed? Can we perhaps encapsulate this in an algorithm
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.
I tried to clarify my intention here (the parsing is defined by the HTTP spec, is what I was trying to say)