(brainstorm) does ‘bots have webids’ remove the need for 'client credentials flow'?

[michielbdejong]

From a gitter discussion, should we eventually investigate/pursue implementing something like https://auth0.com/docs/flows/concepts/client-credentials on our pod servers, or is it enough to just say bots should instruct their users to 'give access to your pod'?

I think I may vote for the latter, I think we don't have so many Solid bot developers yet that run into this need, most Solid app developers are probably working on web apps, right?

[kjetilk]

So, I think my problem so far has been that I don't see apps clearly verified as such, and that makes the whole thing a bit fuzzy for me, so I'd like to take a step back.

Currently, we have a user that can be authenticated, but there may be a bot behind the user, or we get a warning from the user agent (i.e. an Origin header) that the user may actually be code from somewhere else, right?

So, my feeling is that we should first focus on what kind of agents we have.

We could have a user that is verified, in Webauthn terms, and also present, and then we should have a mechanism to verify that an app with code from a different source is actually acting on their behalf, either in their UA or in some other system. This might be an app, or it may be some other batch system, or it may be stuff like an investment broker.

The next type of agent could be classified from warning mechanisms (e.g. Origin), and then, simply "unknown", we know that the user has been authenticated, but it could be a bash script for all we know.

Webauthn is fairly clear about  user verification and user presence, but the situation when some code is acting on some user's behalf, to have verification around that, seems to me to be the critical question, and one that is really fuzzy (to me) now.

Also, I'd like to be able to follow my nose around this, and there #25 seems to be very helpful.

[jaxoncreed]

Just a few of my thoughts following up on this: I see two ways that you can handle the cli use case: You could give the entity with the cli its own webId (You’d need to have an idp deployed for this bot, but Michael Thornborough has previously proposed a soltuion to this inconvenience using self-signed ids) or you could use the client credentials grant from oidc which allows the cli to represent the user herself.

[RubenVerborgh]

Third: there is a separate WebID X representing an agent (with WebID Y) acting on behalf of another agent or user (with WebID Z). By dereferencing X, we find Y and Z.

[kjetilk]

Third: there is a separate WebID X representing an agent (with WebID Y) acting on behalf of another agent or user (with WebID Z). By dereferencing X, we find Y and Z.

Yeah, thanks, @RubenVerborgh and @jaxoncreed ! Indeed, I find this latter possibility very attractive.

Nevertheless, I still feel there is a gap between different types of agents, like identifying them (is it a piece of code or is it an actual human), and having diverse authentication mechanisms (on-disk usernames and passwords isn't very attractive, for example)

[zenomt]

for the "user using a CLI tool" case, what if* the user can list multiple solid:oidcIssuers in her profile. one could be her ordinary issuer (probably her POD), and one could be the self-issuer <https://self-issued.me> #22. the user could then add public keys to her WebID, and the CLI tool could be configured with a corresponding private+public key. the CLI tool could then automatically authenticate (with today's POPTokens or hopefully #25 someday) to any resource server that understands self-issued identities. the POD UI could have a helper/wizard for managing the public keys for tools like this (like, the tool could create the public/private key pair, and the helper/wizard would make it easy to paste in the public key and configure self-issuing in the WebID).

* this is probably already the case today, as long as the logic for verifying the issuer is "is there a triple (webid solid:oidcIssuer iss)" and not "find the solid:oidcIssuer and make sure it's exactly the iss claim".

[zenomt]

when you add "bots/server-side agents have their own WebIDs to which users can grant restricted access to portions of their PODs" then i don't think there's a need for the client credentials flow.

also, ordinary users are unlikely to understand the security implications of the client credentials flow.

[timbl]

After thinking about this, I felt it was useful to standardize how a bot represents in it own profile that it is a bot. Some thinking on the classes at https://www.w3.org/DesignIssues/Bots . - (Which class should we use?)

But also it important to be able to capture the owner/controller of the bot. To be secure, the bot has to claim its owner in the bot's profile, and the owner has to also claim to own the bot in the owner's profile.

[timbl]

I made a bot: https://timblbot.inrupt.net/profile/card#me . Here is an excerpt from its profile.

@prefix : <#>.
@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix pro: <./>.
@prefix n0: <http://xmlns.com/foaf/0.1/>.
@prefix schem: <http://schema.org/>.
@prefix prov: <https://www.w3.org/ns/prov#>.
...
@prefix inbox: </inbox/>.
@prefix sp: <http://www.w3.org/ns/pim/space#>.
@prefix tim: </>.
@prefix c: <https://www.w3.org/People/Berners-Lee/card#>.

pro:card a n0:PersonalProfileDocument; n0:maker :me; n0:primaryTopic :me.

:me
    a
        schem:Person, schem:SoftwareApplication, n0:Agent, n0:Person,
        prov:SoftwareAgent;
    n:fn "TimBlBot";
    n:hasPhoto <image_0.svg>, <noun_bot_2318640.svg>;
    n:note "I am a bot, and I do simple things for Tim";
    n:role "Admin";

...
    n0:name "TimBLBot".
c:i schem:owns :me.

[timbl]

is a

[RubenVerborgh]

schema:SoftwareApplication is likely better suited for the software the bot is running, not for the bot itself (which is prov:SoftwareAgent).

Also, likely neither a schema:Person nor a foaf:Person—I hope 🙂