How do we identify apps?

[zenomt]

in #23 (comment) @RubenVerborgh suggested that

... we probably want to create an issue for the problem we are trying to solve, and work there on adding the desired attributes for a solution, and have separate solution threads.

there are currently two open Issues that propose technical solutions to this problem:

• Proposal: use PoP token issuer (and with that, id token audience) to distinguish web apps #12 Use client_id to distinguish web apps?
• Proposal: recommend WebID OpenID Providers include redirect_uri in audience list to distinguish web apps #23 Proposal: recommend WebID OpenID Providers include redirect_uri in audience list to distinguish web apps

the a problem is that the Origin request header can't be trusted (if it is even present) when bearer-type access tokens are presented vs using cookies, because the presenter might not be the user's trusted user-agent (web browser, command-line tool directly under control of the user, etc). this is because an app that generates or possesses a token could pass it to an agent that isn't under the direct control of the user (like server-side code), that is free to set (or omit) any request header to any value, including Origin.

therefore, a method other than the Origin request header is needed for this case to identify an app to a resource server in a manner that is acceptable and trustable to the user and to the resource owner.

[RubenVerborgh]

the problem is that the Origin request header can't be trusted

I'd rather say:

The problem is that we want to identify apps, i.e., we need a unique identifier for every individual app.
Now we still need to determine the properties of that identifier. For instance:

• With “app”, we mean: …
• The identifier should / should not be different for different version of the app.
• It should / should not be possible to have multiple apps with different identifiers on the same host.
• The identifier must / should / may lead to an RDF document describing the app.

[zenomt]

• it should/should not be possible for the app to impersonate a different app identifier without the user's knowledge or consent
• it should/should not be possible for the user to intentionally impersonate a different app identifier to a resource server
• it should/should not be possible for a single version of an app to have multiple distinct identifiers

[zenomt]

• it [RFC 2119 keyword] be possible for a browser-only app (that is, having a simple, non-active, static-file server) to have an app identifier

[zenomt]

an app is identified so that:

• as a user, i can limit what an app i'm using can do to my own resources
• as a user, i can limit what an app i'm using can do to others' resources
• as a resource owner, i can limit what others do to my resources based on what app the other is using

[timbl]

When you say "the a problem is that the Origin request header can't be trusted" that suggests a failure to distinguished between bots and web apps. Bots do not use the origin header. Webapps only have the origin header, and nothing else. See the a problem is that the Origin request header can't be trusted. See #12 (comment)

If you want to here work on bots -- independent software agents- then can you change the title to "
How do we identify bots", please?

[zenomt]

@timbl the original title of this Issue was "figure out how to distinguish web apps for the bearer token authorization case". i agree that in "first party" cases where the user has logged directly in to a server/service, and is identified by a browser cookie, the Origin header is appropriate and sufficient (and i don't believe there is any other information that could be trusted in this case).

the bearer token case (implemented for some time in NSS and client auth libraries, and being documented in "Various Documentation improvements" #27) is primarily for cases like "i'm using an in-browser newsfeed-like app showing updates, postings, etc from my hundreds of friends and other sources, but i don't want to (or it's impractical to) log in separately to each of my friends' pods and other sources and establish & maintain session cookies with each one". the current solution involves a visible-to-javascript access token to identify the user to resource servers. because this token is visible to javascript (unlike a cookie), it can be trivially shared outside of the browser by the app, including to non-browser agents that could send any Origin header along with the token, and therefore be the user to a resource server but appearing to be using a more privileged app.

i believe the scope of this Issue should be for deciding how best to identify these kinds of apps with the same degree of trustability as the Origin header with first-party cookie-based sessions. both #12 and #23 propose solutions for this specific case.

bearer token authorization is also useful for the "server-side component of an app is acting on behalf of the logged-in user" and the "bot with its own webid is accessing restricted resources on its own" cases.