NASCAR and Web Access Control

[bblfish]

LDP Options and HEAD can return an Allowed-Methods header. It is not clear from the specs if this shows

a. the methods the agent who is accessing the resource with the credentials he has provided can see
b. if these are the methods the agent with the most privileges can use - ie what methods the resource CAN Allow.

• If a server interprets the spec as a. then a client that does not see a method will have to wonder if it would be able to get that method were it to authenticate.
• If a server interprets the spec as b then a client that gets 401ed on trying to use a mehtod will want to find out whether it is even worth its authenticating. Will I get access if I try one of my many credentials?

This is where we then hit the NASCAR problem. Unless the client reads the WAC file it won't know what types of credentials required to be able to act on the resource. So it would have to ask the user to try out all possible ways to authenticate, and none of them may actually be the right ones. This would be

1. very inconvenient for the user as he'd have to try logging in, in many different ways
2. a big source of privacy leaks, as the user would have to try many different credentials before being able to authenticate, and so give away more information about himself than needed.

There was an interesting thread on the Credentials CG, about the NASCAR problem for which we actually have a very useful answer with WAC. I gave an answer that showed how we can solve the problem:

• initial detailed answer
• email rectifying some typos in the original mail detailing the distinction between Authentication and Authorization

[bblfish]

See wiki page https://github.com/solid/solid/wiki/Client-Authentication-Discovery

[dmitrizagidulin]

Closing issue. Discussion moved to:

• solid/#61-all resources MUST have at least one "acl" Link relation
• solid/#45-No way to find out if user is authorized to write to a container