UC3: fixes and add story for privacy

[bblfish]

Following today's panel discussion I added a little twist to show how ACRs can both be readable and privacy friendly. I also fixed a few other problems, and added some clarifications.

[matthieubosquet]

Those are good edits.

However, I don't see/understand what solution to allow people finding out which credentials to present is suggested here. Could you maybe explain in comment?

Even if the access control resources are designed to let a client read which groups can have access to a resource, you would need to know group membership otherwise.

I think it's generally the direction to take:

1. A mechanism to advertised all keys to the door
2. A mechanism to keep and match the keys on the actor's side

But I'm not sure I see it clearly here.

[matthieubosquet]

Suggested change

	Any [digital actor](https://essif-lab.pages.grnet.gr/framework/docs/terms/digital-actor) making a request to `</weekly-status/2021-04-28/report.md>` will receive in the header of a 401, a link to `</weekly-status/2021-04-28/report.acp>`. If that actor makes a `GET` request to that `<report.acp>` it will receive a graph isomorphic to:
	Any [digital actor](https://essif-lab.pages.grnet.gr/framework/docs/terms/digital-actor) making a request to `</weekly-status/2021-04-28/report.md>` will receive in the header of a 401, a link to `</weekly-status/2021-04-28/report.acp>`. If that actor makes a `GET` request to that `<report.acp>` and has permissions to read it, it will receive a graph isomorphic to:

[bblfish]

Btw. who has currently permission to read the acp as stated? Can we make it public now that the group and policy is protected? Otherwise we need to grow the story quite a lot to explain how the client knows what the acp is.

[matthieubosquet]

I wouldn't make it public now, no. And I didn't make that statement. I don't think we should address the "control" part here. It would make everything way too complex and I would much rather address it in a different document. Or at least in a different section of the document.

In all honesty, I start to think control resource management might require its own use case too.

[bblfish]

We need to have implementations descriptions that are realistic, that means they have to interact with clients, and these need to be able to find out how to authenticate. It is not complicated: all the information is already there in the access control rules.

I wouldn't make it public now, no.

why? What is the problem?

[matthieubosquet]

The control question is not answered in the WAC examples either.

The UC3 is supposed to be about inheritance. It is difficult enough to address the concerns related to inheritance to not overload this document with everything else. Otherwise, we'll end up with a massive use case that is extremely complicated.

It's already pretty difficult to comprehend as is.

And we're deviating from or actually not discussing inheritance which is in itself a complex subject that deserves attention.

I find it really difficult and distracting to address all concerns at once.

[matthieubosquet]

This specific use case is about inheritance and does not include the question: "How can an agent discover which credentials to present to access a resource?"

That question is important and we need to discuss it elsewhere, in a specific use case.

A use case stating that Bob is not logged in and has multiple WebIDs and wants to access a resource but doesn't know how to chose which credentials...

I don't want to make up ACLs to be public because it doesn't answer the question asked by a very valid concern and a use case that in my opinion has not been clearly formulated as of yet.

Let's discuss inheritance here.

I'm not dismissing the question of required credentials discovery, on the contrary, I want to address it adequatly.

I agree that we don't have a full fledged protocol without it.

[elf-pavlik]

The UC3 is supposed to be about inheritance. It is difficult enough to address the concerns related to inheritance to not overload this document with everything else. Otherwise, we'll end up with a massive use case that is extremely complicated.

👍 💯

Let's discuss inheritance here.

👍 💯

[bblfish]

This specific use case is about inheritance and does not include the question: "How can an agent discover which credentials to present to access a resource?"

I did not discuss that here. All I did was make the group of Alice and Bob </acp/research#m1> private so that we can deal with privacy concerns. That is not much of a change from the initial story.

We could simplify and say that Alice and Bob are happy for the world to know they are part of the publicly funded research project and so is Carol. The we can make all these rules public and can concentrate on the inheritance issues.

I agree that we don't have a full fledged protocol without it.

It is not acceptable to discuss a protocol for authorization which does not take both client and server into account. It would be like wanting to get married but not consider one's partner in the process. These things come together by nature.
This is especially the case in a decentralised scenario, where clients are jumping from resource to resource. So we should not assume the client is already authenticated. Otherwise, what would be the point of a Linked Data based RESTful authorization protocol?

I don't want to make up ACLs to be public because it doesn't answer the question asked by a very valid concern and a use case that in my opinion has not been clearly formulated as of yet.

You mean the concern "How can an agent discover which credentials to present to access a resource?"

We don't have to make it a concern as we can

1. either stipulate that the agent has been informed via LDN of it's inclusion in the private group under a given ID
2. or make the group public because everyone is ok with that, in which case the client just needs to look at the group description.

We can then later look at more detailed scenarios. We could work on Credentials based versions too if you want. But not including the client is not acceptable.

[matthieubosquet]

It is not acceptable to discuss a protocol for authorization which does not take both client and server into account.

I agree and I am not suggesting not to take the client into account. I am saying that it is acceptable to assume the actor has already authenticated as "Bob" in this specific use case which is meant to address inheritance.

You mean the concern "How can an agent discover which credentials to present to access a resource?"

We don't have to make it a concern ...

I am very confused. On the one hand you insist on talking about the way an actor can understand which WebID or credential to use to get access to a resource and on the other hand you claim it is not a concern.

I think it is important to discuss because one way or another, for sure, LDN is a mechanism that can be useful, for sure an ACR can be edited in clever ways to disclose information that is acceptably publicly readable and maybe even it is all we'll ever need. However, it has not been clearly expressed anywhere and an UC focusing on inheritance is not the place to have that debate.

I think Use Cases focus on different parts of functionality in order to be more comprehensible and it is fine.

I want to extract away from this UC concerns related to:

1. Effective ACR discovery
2. Required Credential discovery

Not because it is not important, on the contrary, because those are extremely important concerns that are not trivial to address and deserve a dedicated conversation.

So does inheritance, which we are not addressing with this debate. I feel like we are in a bit of a deadlock here and I don't think it is necessary.

Please do edit as you see fit because what you suggest does make sense, I just try to push for a slightly different organisation of concerns. Maybe you're right and what I suggest is not ideal. I'm sure we can get to a place which satisfies both of us incrementally.

[bblfish]

It is not acceptable to discuss a protocol for authorization which does not take both client and server into account.

I agree and I am not suggesting not to take the client into account. I am saying that it is acceptable to assume the actor has already authenticated as "Bob" in this specific use case which is meant to address inheritance.

There is no point in developing a story assuming the client has already authenticated correctly as Bob. If it did the client would make a request on the resource and not receive a 401. There would be no story to tell here. There would be no client server interaction with respect to authorization.

You mean the concern "How can an agent discover which credentials to present to access a resource?"
We don't have to make it a concern ...

I am very confused. On the one hand you insist on talking about the way an actor can understand which WebID or credential to use to get access to a resource and on the other hand you claim it is not a concern.

yes, the client (or the wallet's Agent) needs to know what identity to use to authenticate. The reason it is better to start with all resources being public is because it is then very easy to see how the client can using follow-your-nose principles find that out. It is not a concern for us in that sense because we are used to working with Linked Data. So a Linked Data client starting from (1) the resource that returned a 401 can jump to (2) the ACL and from there to (3) the Group document and from there to (4) the WebID Profile of the client's Principal. (each of these steps can be cashed of course, especially the last).

In (1) the 401 also returns with the Link header one or more WWW-Authenticate headers, one of which can be a HttpSig method. This tells the client that it can use a WebKey tied to the WebID. This will let it know what key to use to authenticate using "Signing HTTP Messages". Other protocols are possible, and we don't need to go into those here.

I think it is important to discuss because one way or another, for sure, LDN is a mechanism that can be useful, for sure an ACR can be edited in clever ways to disclose information that is acceptably publicly readable and maybe even it is all we'll ever need. However, it has not been clearly expressed anywhere and an UC focusing on inheritance is not the place to have that debate.

Ok, so let us make these resource public here. There are many other examples where they are protected (I am thinking of the CV examples) where we can go into those. Here we are dealing with research stuff, and it is really not unreasonble to have a story where 3 people are happy to be public about their WebID pseudo identity. After all they need only publish a public key at that WebID! So even with the pseudo published they might not leak any private information!

The privacy concerns are what make the story more complicated (as it would!)
Perhaps we can open up the use case with the CV and do that with the privacy concerns and then link from here to show how those issues are dealt with.

I think Use Cases focus on different parts of functionality in order to be more comprehensible and it is fine.

I want to extract away from this UC concerns related to:

1. Effective ACR discovery
2. Required Credential discovery

Not because it is not important, on the contrary, because those are extremely important concerns that are not trivial to address and deserve a dedicated conversation.

Effective ACR discovery is part of every use case. It is something we can go into more details in other cases, taking on more complex examples such as those requiring privacy. But we can't put it aside.

So does inheritance, which we are not addressing with this debate. I feel like we are in a bit of a deadlock here and I don't think it is necessary.

I think we have addressed inheritance very well. We have pinpointed the current problems of WAC with regard to inheritance and a couple of ways to overcome them. We are also seeing problems with regard to duplication of content, both with ACP and with WAC. We should look at those more closely and see how problematic they are.

Please do edit as you see fit because what you suggest does make sense, I just try to push for a slightly different organisation of concerns. Maybe you're right and what I suggest is not ideal. I'm sure we can get to a place which satisfies both of us incrementally.

I feel the exercise is very successful. I am ok with moving the privacy relevant stuff to a separate story, and make every thing public here to simplify. Perhaps better create that other example first before changing it here though.

[bblfish]

@matthieubosquet wrote:

However, I don't see/understand what solution to allow people finding out which credentials to present is suggested here. Could you maybe explain in comment?

I made some edits to help. But perhaps I need to add a bit more.

The idea was described here:
#189 (comment)

An ACL resource can specify a group who has read/write access. That group may only be visible to the members of the group: ie. the acl of the group gives read access only to members of that group.

How would you know that you are a member of that group? Well you'd need an invite, a message of sorts to your inbox. This is different from say ACLs requesting one prove one is over 18, as those can be public, and only rely on the client having an authoritative credential.

Even if the access control resources are designed to let a client read which groups can have access to a resource, you would need to know group membership otherwise.

yes, that would need to be sent to you for an invite for non-public groups. There is no other way around that.

I think it's generally the direction to take:

1. A mechanism to advertised all keys to the door
2. A mechanism to keep and match the keys on the actor's side

But I'm not sure I see it clearly here.

Can you check out #189 (comment)

perhaps leave a comment there or here if something is not clear.

[matthieubosquet]

@bblfish #189 is clear to me. However, it only addresses one type of credential (group membership) and is not very specific in the way to keep track thereof:

How would you then know you are a member of the group? You'd need to be invited using Linked Data Notification or something similar.

It is an interesting suggestion for best practices in Access Control Resource editing but I think that required credentials discovery should potentially not only rely on best practices and have a dedicated mechanism addressing it. I created #242 to discuss it.

[bblfish]

@bblfish #189 is clear to me. However, it only addresses one type of credential (group membership) and is not very specific in the way to keep track thereof:

How would you then know you are a member of the group? You'd need to be invited using Linked Data Notification or something similar.

It is an interesting suggestion for best practices in Access Control Resource editing but I think that required credentials discovery should potentially not only rely on best practices and have a dedicated mechanism addressing it. I created #242 to discuss it.

The point was to show that you can have ACRs that are widely readable (how much depends on the use case) without loosing privacy: anyone can know that members of some group have access, but without knowing who is member of that group. So the idea that ACRs must be readable by only the controller for privacy reasons is shown to be wrong.

The LDN solution seems to me to be very workable.