Comments (2)
It seems like the IDP could provide the UA with this information at login time instead (via an API, response header, whatever).
It seems like you are proposing that the UA keeps track of all IDPs that are available (empty by default). This list would be kept up-to-date whenever someone logs in at their favorite IDP?
A possible return value enrolled_relying_parties
to indicate whether the user has already logged into the RP before (on another device, for example) might not be available if kept only in the UA and not provided live by the IDP.
Isn't all that's needed a certificate from the IDP that can be used to sign nonces for the RP? Similarly can't the UA track which origins need to be notified of logout?
It may be part of privacy compliance that IDPs provide the user with a list of RPs that have information on the user, even if it is just their email address or identity. Listing the UA (instead of the individual RPs) on that list, may not be desired.
Then again, the discussion being privacy oriented -- maybe it is desired. It gives the user less control over their data from the IDPs perspective (not seeing who used the data), but keeps knowledge about the RP private to the IDP (the IDP does not know about the RPs existence).
Similarly can't the UA track which origins need to be notified of logout?
If the logout happened on that UA, then probably yes.
What if the logout happened at the IDP? How would the IDP revoke the certificate that it gave the UA? JWTs tend to have an expiration time, making them obsolete after a while for this purpose. Given the frequency at which the UA will handle user login (probably not that often), the expiration date for such a certificate would have to be quite long (in the order of days, at least). Then it would almost make sense to make the HTTP request "live" instead.
I hope I'm not stepping on anyone's toes; just trying to respectfully add to the discussion.
from fedcm.
(I'm not on the WebID team, but responding to some of your comments on my comments.)
It seems like the IDP could provide the UA with this information at login time instead (via an API, response header, whatever).
It seems like you are proposing that the UA keeps track of all IDPs that are available (empty by default). This list would be kept up-to-date whenever someone logs in at their favorite IDP?
A possible return value
enrolled_relying_parties
to indicate whether the user has already logged into the RP before (on another device, for example) might not be available if kept only in the UA and not provided live by the IDP.
I agree that would seem to be the case. It seems unlikely to be necessary to have that information. I can certainly imagine it would be useful to provide some sort of UX indication that an IDP has been used before from this RP, but it seems to me that could be accomplished using cross-device sync features that many browsers and password managers have.
Isn't all that's needed a certificate from the IDP that can be used to sign nonces for the RP? Similarly can't the UA track which origins need to be notified of logout?
It may be part of privacy compliance that IDPs provide the user with a list of RPs that have information on the user, even if it is just their email address or identity. Listing the UA (instead of the individual RPs) on that list, may not be desired.
Then again, the discussion being privacy oriented -- maybe it is desired. It gives the user less control over their data from the IDPs perspective (not seeing who used the data), but keeps knowledge about the RP private to the IDP (the IDP does not know about the RPs existence).
It certainly is the case that IDPs can do less with less information. Maybe the desire to be able to list all of the RPs that have been used with your account at an IDP is an important enough consideration to justify this design decision. If so I think it should be mentioned in the explainer.
Similarly can't the UA track which origins need to be notified of logout?
If the logout happened on that UA, then probably yes.
What if the logout happened at the IDP? How would the IDP revoke the certificate that it gave the UA? JWTs tend to have an expiration time, making them obsolete after a while for this purpose. Given the frequency at which the UA will handle user login (probably not that often), the expiration date for such a certificate would have to be quite long (in the order of days, at least). Then it would almost make sense to make the HTTP request "live" instead.
I'm not sure I follow this; is this concerned with:
- making sure my IDP session can be terminated remotely (e.g., if my device is lost or stolen, or my account is closed by an administrator) so that it can't be used to authenticate to RPs anymore,
- allowing me to sign out of all of RPs when I sign out of my IDP, or
- the combination of the two (allowing remote administrative closure of RP sessions)
I'd been thinking of (2), which could be coordinated by the UA instead of what I gathered was the current approach (going to each RP in turn via a redirect or iframe, to have them each delete their session cookie).
Cases like (1) or (3) do seem like if WebID is to address them they would require some form of server contact -- at least online revalidation/revocation checking -- though not necessarily identifying the RP.
I hope I'm not stepping on anyone's toes; just trying to respectfully add to the discussion.
I don't think you're stepping on anyone's toes. Thanks for contributing your thoughts.
from fedcm.
Related Issues (20)
- Preventing silent timing attacks HOT 15
- Iframe-origin in the FedCM UX is sometimes not meaningful to users HOT 14
- Contextualize account selection HOT 2
- Access to FedCM available options (suitable to site) HOT 1
- Context (allow customization in the title) HOT 4
- Consider lifting IdentityCredential out of FedCM spec HOT 3
- Nonce is a sensitive word in the UK
- Use cases for Cross-Site Cookie Access through Storage Access API after FedCM grant? HOT 10
- Align on user flow for initial and returning FedCM prompts
- Should FedCM spec have conformance requirements over IDPs HOT 1
- Autoreauthentication does not work with "silent" mediation value HOT 1
- What is disclosure_text_shown?
- Should getUserInfo() be under IdentityProvider? HOT 1
- Authorizing non-profile oauth scopes HOT 23
- Support for SAML HOT 2
- Need help understanding how the IdP knows what accounts a User Agent is logged in to HOT 2
- The reason we need an ID that isn't just `[RP, IDP]` is that a user could login to a site with multiple accounts. If I sign in as `dan.example` and `dan.other_site` from the same IDP, we need to differentiate those credentials.
- WebDriver capability might have an invalid name HOT 2
- Erroneous link to JSON object in automation section of spec
- Users may be confused after showing intent to sign in but the sign-in is failed HOT 16
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fedcm.