Skip to content
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

Hide RP's identity from IdP in Authentication #27

Closed
gtrs opened this issue Jul 24, 2020 · 8 comments
Closed

Hide RP's identity from IdP in Authentication #27

gtrs opened this issue Jul 24, 2020 · 8 comments
Labels

Comments

@gtrs
Copy link

gtrs commented Jul 24, 2020

The current WebID proposal only hides at which RP a user is logging in from the IdP until the user gives consent to log in using the selected IdP. In particular, the attack scenario sketched in IDP1 is not mititgated (IdP tracks where a user signs-in). This proposal only addresses a slightly different attack scenario, i.e., that any IdP can always track where a user is about to log in.

One possiblity to address problem IDP1 can be similar to the solution that we propose in the SPRESSO SSO protocol. In this protocol, the IdP receives an encrypted string (which we call the tag). The tag contains a nonce and an identifier for the RP. The identifier of the RP, however, we mainly needed to work around browser restrictions. As WebID is probably not subject to such restrictions, it might be even sufficient to just use a plain nonce instead, i.e., just run a challenge/response between RP and IdP.

See https://www.sec.uni-stuttgart.de/research/wim/ for information on the protocol design of SPRESSO. In our research, we also analyzed several other SSO protocols (including BrowserID). You can find our results on this page as well.

@davidben
Copy link

davidben commented Jul 30, 2020

Thanks for the pointer! Does SPRESSO allow for directed identifiers? That is, RPs get handed RP-specific identifiers (e.g. a forwarding email) so that this doesn't become a join key. Skimming the paper, it looks like the user identifiers are still the global ones.

I think the interaction between directed identifiers and IDP1 is the main challenge. Without directed identifiers, two different RPs (and any scripts they choose to embed) have a correlator for cross-site tracking. But directed identifiers mean something in the auth flow needs to look up a consistent identifier by RP. Additionally, RPs typically rely on both a consistent identifier and some communication ability (e.g. email address), so something needs to be able to reverse the mapping to deliver messages sent to this RP-specific communication handle.

[Edit: Dropped "RP1" and "RP2" as names of example RPs, to avoid confusion with the RP1 and RP2 sections in the threat model document.]

@kenrb
Copy link
Collaborator

kenrb commented Jul 30, 2020

There are other challenges to RP hiding. In particular, there are IdP use cases that require them to know the OAuth client ID in the transaction, such as users wanting to revoke credentials from the IdP. BrowserID and SPRESSO are certainly interesting but they do require re-envisioning a lot about how federated identity works today.

As @davidben explains, though, the more fundamental challenge is the apparent conflict between RP hiding and directed identifiers. So far I haven't seen any schemes that would allow us to have both.

@surfnet-niels
Copy link

surfnet-niels commented Aug 31, 2020

Another issue with RP hiding is that for an IdP to release personal data during the The Provisioning Stage it needs to able to assess where the data is going.
Several factors may determine the willingness of an IdP to release data like:

  • EU vs non-EU based RP (e.g. for GDPR compliance)
  • Licensed content vs freely accessible (Do I as an IdP run the risk of getting a bill?)
  • Brand association: User may interpret the ability to login using the IdP as a form of sanctioning of the RP by the IdP. However IdPs may not want their brand to be associated with all RPs (e.g. academic IdP providing login to gambling/porn)

All of the above are risks which will be assessed by an IdP before deciding to release data to an RP. Requiring IdP to release personal data into a 'black hole' because the target is not revealed will make such risk assessment impossible and hence release of PI will be challenging.

@davidben
Copy link

The provisioning stage isn't about releasing data to the RP, just providing the UA with any RP-independent information that may be needed to display the initial browser-level consent prompt. (One could even imagine something analogous to the Payment Handler API, which has the payment provider register a set of instruments with the browser.)

Such a split would still allow the IdP to take the RP into consideration once the browser is okay releasing that information to the IdP. The IdP is ultimately the one minting the IdToken.

@samuelgoto
Copy link
Collaborator

I think this makes general perfect sense.

BrowserID and SPRESSO are certainly interesting but they do require re-envisioning a lot about how federated identity works today.

I think re-envisioning is perfectly fine.

In this protocol, the IdP receives an encrypted string (which we call the tag). The tag contains a nonce and an identifier for the RP.

This is a similar mechanism that describe here in the delegation-oriented variation.

@gtrs any chance we can arrange a call for you to walk us through SPRESSO and compare and contrast approaches?

@gtrs
Copy link
Author

gtrs commented Mar 27, 2021

@gtrs any chance we can arrange a call for you to walk us through SPRESSO and compare and contrast approaches?

Sorry for the delay. Sure, I am happy to give you a walkthrough. Until Easter I am pretty busy. Maybe we can schedule a meeting after that?

@samuelgoto
Copy link
Collaborator

The current WebID proposal only hides at which RP a user is logging in from the IdP until the user gives consent to log in using the selected IdP. In particular, the attack scenario sketched in IDP1 is not mititgated (IdP tracks where a user signs-in). This proposal only addresses a slightly different attack scenario, i.e., that any IdP can always track where a user is about to log in.

Just to report back on this thread: we wrote down in more details how we think we may want to go about solving this problem here. It is still early, but that's the best place to have that discussion.

@samuelgoto
Copy link
Collaborator

We are actively working on this problem at the Digital Credentials API, which solve this problem by breaking the IdP into a holder and an issuer.

https://github.com/WICG/digital-identities

I'm going to mark this as closed, since we were constrained by backwards compatibility, and allow the Digital Credentials API to address this issue.

Feel free to re-open if you feel like there is something in FedCM, specifically, that we could address.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants