Express what expectations users should have of acl:AuthenticatedAgent

[kjetilk]

In solid-contrib/test-suite#36 , I found that a custom IDP that simply gave away bearer tokens without attempting to authenticate a user would best fulfill the needs of a test suite. Then, I had second thoughts, because the existence of such an IDP would subvert the mechanism of acl:AuthenticatedAgent. I figured we should therefore have some kind of shared secret between a test runner and the system under test. But then, I figured, if we can create such an IDP, so can anybody else.

We can certainly specify that an IDP must authorize an agent, there could even be laws against it in some jurisdictions, but we probably cannot make them go away entirely if there is value to some.

Thus, acl:AuthenticatedAgent does not mean acl:ReasonablyWellBehavedAndKnownAgent, it is marginally different from foaf:Agent, in that you could have agents with a valid bearer token that has been through no authentication process.

Whether this should make us re-evaluate whether acl:AuthenticatedAgent should exist at all, or if we should just adjust user's expectations towards it, I don't know, but it should be discussed.

[acoburn]

In OIDC/OAuth, there is typically a pre-existing trust relationship between the IdP and the RS. Absent that initial trust relationship, the RS cannot validate the signature of that bearer token and the HTTP request will not pass through the authentication stage.

[dmitrizagidulin]

I agree, I'm not sure acl:AuthenticatedAgent is that useful.

[zenomt]

acl:AuthenticatedAgent is useful for at least these two cases:

• anyone can post a chat/comment/whatever to X, but they need a webid (that is, no anonymous posts)
• anyone can access my X but i want to know who it was later (perhaps in a log file or audit trace)

just because an IdP gives out a signed id_token that says it's for webid W doesn't mean that it's really W. W still has to say that IdP is an Authorized Issuer for its identity. it's between W and IdP how authentication happens, and isn't really anyone else's business.

[kjetilk]

@zenomt my point is that since authentication happens between W and IdP, someone can set up an IdP that doesn't authenticate, and so, anybody can do anonymous posts. I.e. acl:AuthenticatedAgent cannot be relied on for those two cases.

[dmitrizagidulin]

I agree. In addition, even without a fake IdP, it is absolutely trivial to create a throwaway WebID (it is literally a single API call, or a few seconds filling out a web form), so I'm not sure how much value that WebID would have (it's not much better than anonymous posting or for access logging purposes).

[zenomt]

i think acl:AuthenticatedAgent means "the agent has authenticated and proved its webid to me (the resource server) with like an Authorization header", not "the agent has authenticated in some reasonable and secure way with its identity provider".

making a new transient webid might be trivial, but having a new domain for the webid (or its issuer) is more work. if this were to become a problem in the future, an abusive hosting or issuing domain could be blacklisted.

and i think at "web scale" there's value in "i want to know your webid even if i don't know you specifically already". especially for the friend-request case, but also for commenting or other open collaboration scenarios. acl:AuthenticatedAgent forces a webid to be proved to the server, so that it can be used.

[kjetilk]

Indeed, this is essentially about setting expectations, but I think the expectations might have exceeded what can reasonably be delivered.

[csarven]

Good issue @kjetilk .

@dmitrizagidulin Point well taken about how one can get around it by creating a throwaway but it comes down to why a server may need to have an agent go through the authentication process. I find @zenomt 's comments quite adequate as a response to the concern.

Is acl:AuthenticatedAgent used in implementations in a way that's different than what's outlined in https://github.com/solid/web-access-control-spec#authenticated-agents-anyone-logged-on ?

@zenomt re:

anyone can post a chat/comment/whatever to X, but they need a webid (that is, no anonymous posts)

The use case makes sense but we don't currently have a strict definition for "anonymous". I would generally say that it doesn't necessarily mean no WebID ie. "unlinkable". It could simply be a WebID Profile with no description or claiming itself to be "Anonymous" (perhaps by name/label or some other description) - which is to say that it is a WebID that's intended to engage anonymously - certainly different from pseudo-anonymous identities. "Anonymity" should not to be conflated with "unlinkability". So, I think the use case you're describing is along the lines "linkable identities only".

To be clear, acl:AuthenticatedAgent effectively ensures linkable identities. A server or an application may have additional requirements eg. must have a name, has certification x. Any sort of trust on that is orthogonal and we shouldn't couple them together.

Edit: mixed up my authn/z in the paragraph above. Simplified what I really wanted to say.

[kjetilk]

OK, I can accept that view. So, I think this is more about setting expectations right. I'll adjust the title to reflect that.

[csarven]

Unclear if there is a particular finding that will be satisfactory to close this issue but I do think that the definition of AuthenticatedAgent is sufficiently clear and can be distinguished from foaf:Agent (at least perhaps in context of agentClass use). Authentication mechanism is orthogonal here.

Closing this issue and moving it to the WAC repo. People can still chime in and we can reopen if necessary. The current WAC Editor's Draft: https://solid.github.io/web-access-control-spec/ requires AuthenticatedAgent and gives a simplified description of the term in ACL ontology "Allows access to any authenticated agent."

[kjetilk]

I have still had a bit of an issue with this, but as @timbl clarified in an Editor's meeting, it doesn't need to be thought of as a security mechanism at all, it is useful to ensure that some identity is conveyed. However, I think this user expectations should still be managed by a paragraph in the Security Considerations section of the WAC spec. I would therefore suggest transferring it back to the spec repo and reopen.