Meeting minutes
Introductions and announcements
acoburn: Slightly smaller group because it's august people are on vacation. AC is still in catchup mode.
acoburn: Lawrence sent out a message about face-to-face meeting. There's an RSVP link. Could people remember to RSVP so he knows how many people to account for.
Action Items
acoburn: The only action item is related to use cases. But, there aren't any new ones this week. If anyone knows of new requirements let me know. (no one has any)
acoburn: Please type out the full acoburn
Continued clarification of requirements (from Auditable Trail )
TallTed -- Tab completion does work (I have confirmed it does)
acoburn: The next requirement is "Auditable Trail"
Auditable Trail
acoburn: We want to focus on clarifying the requirements rather than rabbit holes on the solution. We could possibly finish today.
acoburn: The requirement is to access an auditable log of access requests. Specifically about auditablity of access requests and grants. It also includes auditability of resources being created, modified, or deleted.
acoburn: How much should be part of the HTTP API, and how much should be internal details?
dmitriz: It's 99% internal details, but the API should expose a link to the auxilary resource. We need a way to discover the auditable log, but everything else is internal
acoburn: Would it be required that an auditable log is available, or would that be an extension.
dmitriz: No.
<pchampin> +1 dmitriz
dmitriz: Most of it would be internal.
dmitriz: One is a log of http requests, and the other is a log of what agents have requested. These are different.
acoburn: There was earlier work in combining audit-related requirements. We might want to split it into one requirement related to access requests and another one that is a part of an extension that has to do with logging resource creation/modification etc.
<dmitriz> sounds good to me
<pchampin> +1 to split them
acoburn: Someone to open a PR to split those?
<laurens> +1 to split out audit logs for permission delegation and audit logs for resource acces
hadrian: I would open it, but could you clarify the request
acoburn: Right now there's an auditable trail requirement but it has two portions: accesing logs of grants, and the other is about logs of modifications to resoruces. The first is more akin to what should be available on an HTTP API, and the other is about an internal audit log that would not be a part of a core requirement.
Data Sharing
acoburn: If I'm a storage owner and I want to get read/write access to a thrid party.
<dmitriz> +1, does seem fairly core\
acoburn: Seems like something very core to LWS
<eBremer> _1
<Jackson> +1
<eBremer> _1
<eBremer> +1 :P
<pchampin> +1
ryey: I want to ask for verification: Does this only involve reading/writing rather than "control?"
acoburn: I would say this has to do with granting some kind of access. I don't think we even need to define the kind of access.
dmitriz: I think it's fine as is. But, to give more details I'd like to add "grant access to known parties" and "access to unknown parties. Ex: anyone with a link can..."
acoburn: Dmitri, can you edit the requirement.
dmitriz: Yes, what's the procedure. Should I go the issues, or should I make a modification to the document directly.
acoburn: Make an edit to the document directly
hadrian: To clarify, when you say "everyone with a link" do you mean everyone authenticated or do you also include non-authenticated people
dmitriz: Both are useful for both
hadrian: That goes into audit trails
dmitriz: It does so we'd need to handle that.
dmitriz: Because creating an account is trivial, there's no difference between an IP address in the access log and a random username in the access log, so I don't see the difference.
acoburn: The high level point is we want two axies of data sharing: by identity or by capability. But, we don't need to go into the details now
TallTed: You should see a use case the flows into stories if you scroll up or down. If you look at #5, I think it will be better to have a blank line. It will visually separate issues and stories.
acoburn: That will help folks read this. Hadrian, could you make a PR for it?
hadrian: Absolutely
Adding Updating and Deleting Resources
<Zakim> TallTed, you wanted to make a meta request that both `Issues` and `Stories` be styled to have "open spacing" (i.e., blank line above them). Currently, only `Issues` do, so if there's no `Issues` paragraph, `Stories` are right below the UC summary.
Eric: Things to think about: Do we want to delete many files with a single deletion? Do we want a more command (for a version 1 spec they would be for the same server). It would be interesting to have things between servers, but that gets complicated. Do we want copy move with append?
TallTed: I ask that you capture that in an issue so we don't forget it.
<dmitriz> I'm certainly a fan of the http COPY command, at very least. (I proposed it for solid, way back in the day, and implemented it in life-server).
Erich: Yes, I'll take care of it.
<ryey> Worth adding #171 to this requirement
<gb> Issue 171 not foundacoburn:
acoburn: What do people think about #7? It seems core
acoburn: No comments, so we can move on.
Storage Portability
acoburn: Are there clarifications to this requirement that help us prioritize it?
dmitriz: I'm not sure the last sentence makes sense. The export and import part and portability of the data model is the point. What happens to the provider complicates it.
<TallTed> "everything moves, with same permissions" is relatively easy. "links still work" is hard.
acoburn: Are there any concerns about removing the last sentence?
TallTed: The last sentence might imply that the original storage provider is not responsible for redirect URIs, but it is a valuable ongoing service.
acoburn: Is that going to be a requirement or will it be optional?
TallTed: I think optional is the way to go, but I think we should talk about whether or not it's required.
acoburn: We'll have a set of requirements in the spec, but we'll also have sections on "portability considerations" or "security considerations," and this might make it into "portability considerations"
dmitriz: I wanted to add a clarifying datapoint. When we discuss data porability in the social web working group. We differentiate between portability between living servers and dead servers. Different solutions apply for dead servers.
acoburn: Certain kinds of URI structures could provide portability automatically. There are considerations there. Things like WebVH might provide protability in the URI itself, whereas a plain URL would require the interaction of different servers.
acoburn: Is there more to discuss on storage portability?
Transfer of Control
<hadrian> correct
acoburn: This is about taking an existing storage with an entity that controls that storage and reassigning it to some other entity.
<TallTed> As written, that looks like "transfer of ownership"
<dmitriz> I'd disagree - ownership is orthogonal to control
TallTed: That sounds like transfer of ownership.
<dmitriz> (ownership involves weird legal considerations, whereas control doesn't quite)
ryey: I don't remember if there's a requirement talking about multiple ownership or control of the same storage. Therefore, for this item that only allows transfer rather than allowing for two different entities having control over the same storage
<TallTed> (we definitely want to avoid weird legalities where we can, but... maybe this case requires clever definitions no matter what else is involved)
acoburn: We'll get to "each storage should have one controller" in a moment. Those all relate to the question you're asking.
hadrian: For Ted: Yes Ted, there was a discussion about verbage. We chose "control" because "ownership" is nebulous. For Ryey: Control may have to be one entity that could be a group.
<dmitriz> my proposal with this is - we completely avoid the 'owenrship' term. and just use control. (and don't restrict it to just one entity)
<dmitriz> yes, for example, Data Integrity keys used to have an 'owner' field, way back, in the first iteration
acoburn: There are other specs in W3C land that have addressed this issue of "ownership" vs "control." Does anyone know which ones have worked through this issue and where they landed?
<dmitriz> but it got changed to 'controller'
TallTed: Unix-like operating systems refer to "owner" and not "control"
TallTed: When designating "owner" or "controller" the best practice would be to use a URI and that URI could be an individual, or a group, or any other kind of agent.
<dmitriz> I agree, no reason to differentiate groups vs individuals
<TallTed> Ownership *can be* a legal term. It's not guaranteed to be.
dmitriz: Ownership is a legal term which is different in every jurisdiction. Control has an authorization/access control definition. I strongly recommend saying "controller" instead of "owner." Data integritiy key serialization used to have an owner field, but it got changed to controller.
<pchampin> An interesting read on the notion of "data ownership" https://
acoburn: We will need to sort this out more formally, but I will open an issue about clarifying that terminology.
hadrian: I'm neutral to which term we use. The discussion did take place before in the Control Identifier group. This is not about data ownership it's about control of storage. So, we should make a decision as quickly as possible. We understand the same thing, it's just choosing the right word.
acoburn: Any other conversation for "transfer of control" and what it means as a requriement?
Delegation of Control
acoburn: Should 3, 4, and 5 be combined into a single requirement with sub-topics? Any preference?
Control of Storages
<dmitriz> I'm curious about the 'exactly one' restriction
<dmitriz> why did it come about
acoburn: This says and entity should control one or more storage and that a storage should only have one controller
dmitriz: Where did the exactly one restriction come from?
eBremer: It came from Hadrian
<TallTed> "exactly one controller" can make sense *if* a controller identifier can denote a group/list.
<TallTed> again, consider Unix-like filesystems
hadrian: The first part is self evident. For the exactly one restriction, it's about how you model a controller. It's much easier if storage has one controller. If that controller is more than one entity (like a group) the composition of the group can be managed separately without the control of the storage being changed.
dmitriz: I think it makes sense, but I'm not sure the restriction is necessary. It could be implementation details.
hadrian: If you don't do that then servers CAN have multiple controllers and that complicates things. Making it a requirement simplifies the implementation effort.
dmitriz: I think it presumes implementation details.
acoburn: If we have a restriction in place we need a rationale as to why that restriction is there. I would say "A storage must have at least one controller" rather than "only one controller"
acoburn: I feel like removing the last line or changing it somehow might be good.
hadrian: Can there be an entity with no controller? Oh at least one
Jackson: hadrian, can you give examples of how multiple controllers make things complicated?
<dmitriz> to me, that's just like saying "a storage should only have one user account". why not multi-user servers? well, those are more complicated.
<dmitriz> so it's like, yes, of course multi user is more complicated. but there's no reason for the spec to restrict that
hadrian: Think of how the implementation is going to go. If there are more controllers, how are they represented? A list, rows, legal entities? But, I'm not clinging to it. I thought this was a better way to do it. I thought this was a simplification.
<dmitriz> yes, we're specifically saying - 'controller' property should be an array, optionally
hadrian: If you implement it the way I thought as a group, then it's kind of like delegation. In a way.
Jackson: I can see how multiple controllers can "compete" when changing things. Having a group as a single owner seems to have the same complexity.
acoburn: I think at this requirement stage, we should avoid this level of restriction. When we get to the point of drafting text, we can add certain clarifications. I think it would be better to strike the last sentence or change it to "as storage should at least have one controller."
hadrian: I'll create a PR for it.
<Zakim> ryey, you wanted to discuss "Storage" only, or also "Resource"?
ryey: I just scrolled down the list of requirements. There's only mentioning the controller of the storage and not the controller of the resource. That implies that the controller of the storage is the same as the controller of the resource always.
acoburn: This gets into the question of how the authorization system works. Is it heirarchical? Is it some other system? At the storage level, we want to be sure there is a controller of a storage overall. It implies that you also control the resources in the storage.
acoburn: Could you, ryey, open a new issue or add a comment to the existing issues asking the question "does control of a storage imply control over the resources of that storage?"
acoburn: We'll defer the last two to next week?
ryey: One possible authorization mechansim, SAI, uses an agent that modifies the authorization. That agent is not the controller of the storage. So, that's an example where there's a difference.
acoburn: Let's continue the discussion in the issues.