Policy statements (proposed for .well-known/webid) should be RP+IDP pairwise, not IDP global

[hillbrad]

It is likely that integrations between RPs and IDPs will exchange different sets of information depending on the RP use case. Some IDPs may need to know the RP identity for every account created that involves sharing certain types of information, e.g. in order to provide management and audit capabilities (e.g. data deletion requests as required by GDPR, revocation of long-lived OAuth capabilities). A more lightweight login that is auth only, without attribute exchange, might not need that. Ultimately I think this requires that the trust framework policy declaration proposed for .well-known/webid needs to be for the pair of RP+IDP, and not globally for the IDP.

It does raise an interesting question of how to check for such a policy without revealing the RP identity to the IDP. Perhaps the RP can declare that it needs an RP specific policy, and the IDP generic one is the fallback for ceremonies not-so-annotated.

[samuelgoto]

It is likely that integrations between RPs and IDPs will exchange different sets of information depending on the RP use case. Some IDPs may need to know the RP identity for every account created that involves sharing certain types of information, e.g. in order to provide management and audit capabilities (e.g. data deletion requests as required by GDPR, revocation of long-lived OAuth capabilities).

Ah, interesting observation!

Question: are these use cases enumerable? That is, is there a limited / enumerable number of classes of situations that represent ALL RPs? That is, can we turn this into a global policy that covers all of these variations. For example:

I, the identity provider, offer the following terms for my service:

• for RPs that need A, B, C, our policies are X, Y, Z
• for RPs that need D, E, F our policies are P, Q, R
• ... and so on until we exhaust all variations ...

Would this work?

That is, are the principles around those RP-specific policies fixed?

[hillbrad]

They are probably enumerable, but only at a very high granularity. Perhaps very roughly something like:

• The IDP will not learn that you are using this RP.
• The IDP will learn that you are using this RP and will use that information only to allow you to manage your relationship with the RP.
• The IDP will learn that you are using this RP. The IDP may use this information to allow you to manage your relationship with the RP, and the RP and IDP may share information about your account and activity for purposes related to the protection of your security and privacy and the prevention of fraud and abuse at their services.
• The IDP will learn that you are using this RP. The IDP may use this information, and the RP and IDP may share information about your account and activity, for business purposes as described in the following terms of service.

[achimschloss]

@samuelgoto I think the cases are enumerable if we look at it from a legal basis perspective (which will map to the IDP policy as well as the RPs Policy) based on which a transfer happens from IDP to RP.

An IDP would usually differentiate on which legal basis a certain piece of information is transferred from IDP to a specific RP and maintain an IDP/User to RP specific out-of-band (for the browser) privacy "matrix" (federated IDP will typically then offer centralised privacy controls that allows a user to inspect these relations and legal grounds for data transfers and manage them)

for RPs that need A, B, C, our policies are X, Y, Z
for RPs that need D, E, F our policies are P, Q, R
... and so on until we exhaust all variations ...

Would this work?

In general it might - typically an RP would request a certain piece of information (A) from an IDP based on the IDPs policy for a specific API call and will run the user through a fitting flow. That simply means a user will be informed and asked to authorise or consent (which the IDP can only do knowing the RP) to the data transfer if he did not already in a prior interaction - As noted an IDP maintains an out-of-band permanent privacy status for a user.

It is important to note here that an IDP cannot simply transfer data or support the transfer of data without knowing the recipient (RP) from a regulatory perspective (GDPR for example). It think the same holds true for the payment API that you are referring to, where the payment provider needs to know the merchant to execute a payment transaction.

In that sense I agree with @hillbrad that you cannot generally hide the RP from the IDP.

Having that said, this is a quite complex topic in details as it goes deep into privacy regulation. I think it would be worthwhile to extend the .well-known idea with support for an explicit deep link into the IDPs privacy controls and / or have a bit more granular privacy policy breakdown.

[achimschloss]

Usage of information that the IDP becomes aware of unavoidable by the IDP itself other than fraud, security ... and to manage the relation to the RP is a completely separate topic in my view.

This is basically the differentiation between a pure play IDP (not doing it) and what one might call a social login as a category (usually does it). From a users perspective this would be worth surfacing at least in the browser declaration directly

[npm1]

It is not acceptable from a privacy perspective for the well-known file to be dependent on the RP. So I don't think we can consider what is suggested in the title of this issue. An IDP can already choose what to share with the RP at the id token creation time, as it will know the RP at that time. Is it ok to close this issue?

[samuelgoto]

Since this was filled, we made tons of progress, much of which, I think, suffice to close this issue. Feel free to re-open if there is still something that we should act on.

Ultimately I think this requires that the trust framework policy declaration proposed for .well-known/webid needs to be for the pair of RP+IDP, and not globally for the IDP.

We introduced the client_metadata_endpoint which allows the IdP to send RP-specific privacy policies and terms of services, without incurring into a tracking vector (credentials are not sent).

It does raise an interesting question of how to check for such a policy without revealing the RP identity to the IDP.

In addition to the client metadata endpoint, I think there are a couple of API extensions that we are actively working on (and hence, a more active duplicate of this) that would allow any type of extra permissions that the IdP need to gather (knowing who the RP is) before anything is returned to the RP:

• Allow IdPs to continue and finish the request in a popup window custom-requests#1 allows the IdP to continue the authorization flow in a pop-up window, knowing who the RP is
• Allow RPs to selectively request attributes of the user's profile custom-requests#4 allows the RP to entirely skip the selective disclosure dialog, so that the browser prompt is limited to account choosing

I think, once w3c-fedid/custom-requests#1 and w3c-fedid/custom-requests#4 are resolved, this issue will be fully resolved, so I'm going to mark this as a duplicate and carry on there instead. Feel free to re-open if you feel like this issue wouldn't be addressed by those and there is something else actionable here.