[Discuss] Abuse preventions and mitigations

[timcappalli]

Surfaced as a core discussion topic on the first call (2023-10-04).

Sub topics:

• Risks for persistent/global identifiers

[OR13]

The traditional solution I've seen to this problem is to mandate "application specific identifiers", and then to try to design the protocols to always mix the application context... at least at the hardware layer... mitigating globally unique / persistent identifiers as claims about subjects in general, seems to defeat the purpose of many credentials, for example:

• https://www.tsa.gov/travel/frequently-asked-questions/what-known-traveler-number-ktn
• https://www.federalregister.gov/documents/2022/03/02/2022-04322/global-business-identifier-gbi

[npdoty]

I think this would include at least:

• strong identification/authentication of who's requesting the credential
• clear indication of for what legitimate purpose a credential is being requested
• external review of the legitimacy of the request, which can be checked/consumed by the user agent
• external accountability when sites make illegitimate requests
• mechanisms to report abuse (to the UA and to third party reviewer)

[samuelgoto]

Thanks for the feedback! Quick clarifying questions!

strong identification/authentication of who's requesting the credential

Is requiring HTTPS for the requesting site sufficient for strongly identifying the requestor?

clear indication of for what legitimate purpose a credential is being requested

Is the indication given by the requestor?

external accountability when sites make illegitimate requests

Can you give me concrete examples / principles that we an external entity would/could use to delineate between legitimate and illegitimate requests?

[npdoty]

Thanks for the feedback! Quick clarifying questions!

strong identification/authentication of who's requesting the credential

Is requiring HTTPS for the requesting site sufficient for strongly identifying the requestor?

An origin, with transport guaranteed by HTTPS, is a good starting point, if it's limited to the top-level page. I don't know that we have evidence that users have high confidence about that distinction, but I also don't know that we've had luck with more extensive validation of the organization behind a origin.

clear indication of for what legitimate purpose a credential is being requested

Is the indication given by the requestor?

Requestors would need to provide the detail of the purpose, because it would be in the context that they are requesting it (surrounding site documentation, etc.). But given the likelihood for abuse, accountability mechanisms (either pre-registration and approval, or an effective regime for reporting and disabling abusive requests) would seem to be necessary.

external accountability when sites make illegitimate requests

Can you give me concrete examples / principles that we an external entity would/could use to delineate between legitimate and illegitimate requests?

We can and should try to document principles of what is or isn't generally reasonable, even if there may not be universal consensus on that. (Confirming your government credential with a government benefits website seems legitimate; a news site asking for your government credential to improve cross-site ad targeting on their site doesn't.)

Data protection authorities are probably best positioned to evaluate whether a request for government-issued credentials is legitimate -- whether it's legally required, proportionate, whether protections are in place, etc. My understanding of EU regulation is that they would require pre-registration of these purposes/requests, and would need some way for a requestor to point to their approved pre-registration.

[samuelgoto]

An origin, with transport guaranteed by HTTPS, is a good starting point, if it's limited to the top-level page.

Yeah, good point: I think we can easily limit the invocation of the API to top-level frames.

I don't know that we have evidence that users have high confidence about that distinction, but I also don't know that we've had luck with more extensive validation of the organization behind a origin.

It would be great to hear if you have other ideas / suggestions here, but in the meantime, I'm going to interpret your response as "origins and HTTPS seem like a good starting point".

Requestors would need to provide the detail of the purpose, because it would be in the context that they are requesting it (surrounding site documentation, etc.).

Can you expand on this a bit more? Can you give me examples on what you mean by "details of the purpose"?

But given the likelihood for abuse, accountability mechanisms (either pre-registration and approval, or an effective regime for reporting and disabling abusive requests) would seem to be necessary.

Can you expand on this too? Can you give me examples of what kinds of abuse you can anticipate? What are some of the most concerning ways we could see abuse here?

Confirming your government credential with a government benefits website seems legitimate; a news site asking for your government credential to improve cross-site ad targeting on their site doesn't.

Yeah, that seems to me like to fit clearly in the opposite extremes of the spectrum between legitimate and illegitimate use cases ...

Would you agree that the user can help the user agent making a distinction between these cases too?

[timcappalli]

related to #35

[npdoty]

But given the likelihood for abuse, accountability mechanisms (either pre-registration and approval, or an effective regime for reporting and disabling abusive requests) would seem to be necessary.

Can you expand on this too? Can you give me examples of what kinds of abuse you can anticipate? What are some of the most concerning ways we could see abuse here?

This is a big question! I'm using this document on user considerations for credential presentation on the web (and the Privacy Interest Group (PING) will continue to contribute to it) to gather some of the concerns, including around abuse. In very short, surveillance, discrimination and exclusion would be the most significant top-level categories.

[npdoty]

Requestors would need to provide the detail of the purpose, because it would be in the context that they are requesting it (surrounding site documentation, etc.).

Can you expand on this a bit more? Can you give me examples on what you mean by "details of the purpose"?

When a user is asked to share high-assurance credentials, which may be government-issued and include details that are permanent or very difficult to change, uniquely identifying and connecting to a physical location and legal identity, the user will need considerable detail about why a credential is being requested in this context, why the elements are needed and what they're being used for.

brainstorming: "To sign up for this governmental program, Agency X may access, with your permission, your name and identity number in order to confirm your eligibility for the program, as required by Statute Y. This data will be used to confirm your identity, your income level and citizenship status. Data Protection Authority Z has confirmed that this is a legitimate request and that policies and technical mechanisms are in place to assure that your credentials are not used for any other purpose or shared with other parties."