login mediation: why contact the IDP to get the account list? (and related questions)

[jeremyroman]

It seems like the IDP could provide the UA with this information at login time instead (via an API, response header, whatever). As currently presented, it seems to contact the IDP (with credentials) every time the user visits a site which could possibly be logged into (before they actually log in). If it is necessary, it would be great to briefly explain why.

I don't follow the reason for contacting the IDP at login time either; the main document alludes to backward compatibility issues, and I've tried to understand the slides for the "delegation-oriented" system but I don't quite follow. If something new is being invented, then at least for the login (no permission delegation) case, 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?

[EtienneBruines]

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.}

[jeremyroman]

(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:

1. 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,
2. allowing me to sign out of all of RPs when I sign out of my IDP, or
3. 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.