Global Task Exchange Protocol(github.com) |
Global Task Exchange Protocol(github.com) |
The final piece of our centralized Authentication and Authorization strategy is a security server that allows a client with an OAuth2 Bearer token to access the user-group system, role-permission system, and to authenticate to our applications on behalf of a user using JWT. We're still working on a UI that will allow delegated administration (we've got 200k active users to manage) so that a manager will be granted the right to administer certain roles-permissions and it's then their responsibility for making sure their employees have the appropriate permissions.
We're in the process of adding ABAC style permissions so that we can manage user access in n-dimensions while slicing data (an employee might be allowed to manage financial data per the RBAC roles they're assigned but we also need to make sure they can only charge expenses to accounts that they're responsible for and potentially to apply limits to what they can spend without higher approval).
The first parts of our system are functional and we'll be rolling several applications with simpler permissions out over the next two months. We've actually been thinking about this problem for over three years, implemented the first of the ANSI RBAC roles over two years ago and we're finally getting the last pieces in place to make the whole system work. The only outstanding question is whether we can create a centralized UI for managing ABAC controls since these controls commonly require the context of the external application to make any sense.
In any case, I hope the two links below help!
[1] http://csrc.nist.gov/groups/SNS/rbac/documents/draft-rbac-im...
[2] http://directory.apache.org/fortress/
P.S. I should also mention that the system that's been running for two years now provides RBAC for over 3M users with our non-privileged accounts.
> Task is owned by a Project. Project belongs to a User. User is a member of Domain.
Can Tasks have subtasks? Recursively? To an arbitrary depth?
Can Projects have subprojects? (see above)
I assume since a "User" is just an email address, a group email address would implement a "Group" at the "User" level?
In a company setting, Users (Contractors, Employees) come and go during the life of a Project. What happens to Tasks assigned to a User who leaves the (company|Domain|Project)?
Recursive tasks works exactly like recursive calendar events.
I have not thought about Sub-Projects, any suggestions?
User-Group - That is interesting, I think it should not change the behaviour based on the Type of email, which is difficult to determine.
When a user leaves do the same thing as email - either purge them all or re assign it to someone else.
That should work.
> Recursive tasks works exactly like recursive calendar events.
I'm not sure what a recursive calendar event is. Are you reading "recurring" instead of recursive?
> I have not thought about Sub-Projects, any suggestions?
The same `Parent-Id` solution as subtasks should also work here.
As an example, getting widespread adoption of a new TX DNS record type is unlikely, though you can fake it with TXT records.
That is right. I will update the proposal thanks!
Thanks a lot for the suggestion. I love what IndieWeb is doing.
Maybe this could start as a thinner protocol, with adaptors to turn Todoist, Asana, Trello and Basecamp into clients.
From a pragmatic perspective, I'm not sure this can gain traction. The mail exchange protocol was built in a very different environment, and you'd have to get some serious weight behind this to gain much traction.
To me, the more intriguing question is this: what sort of _new_ task management apps could and would get built on an interoperable platform?
One end result of the lack of interop in this space is that commercially viable task management apps trend toward being all things to all people. There is a legitimate need to satisfy a very wide variety of use cases.
If task management apps could interoperate on a common set of data, it might become feasible for much more narrowly scoped, purpose-built apps to succeed.
This is not limited to interoperability, cross domain / organization collaboration tool. It is almost like asking what sort of e-mail tools can be built on top of email protocol.
You are right about the commercially viable aspect. But if I wanted to make it commercially viable I would not have made it open.
I think something like this WILL be the `interoperate` set of data that you are talking about.
Yeah, sounds trivial.
For example - Project management involving multiple Organization. - Freelancers to work closely with the team - Open source Project development
Let me try to explain: A task is not just a text, it has context and history, and meta data. Unfortunately people use email for this which creates 100s of messages in a thread. Instead, if you keep single entity and keep updating it like you would do in any task management system, it will create better meta data and less headache to manage.
yes! sorry i misunderstood. and now we have solution to both recurring and recursive!
> The same `Parent-Id` solution as subtasks should also work here. Yes, it will - but does it complicate the architecture ?
As far as I think, it is straight forward. But I also agree when you work in a complicated hierarchy, you probably need these systems.
EDIT: I also should have mentioned that we're updating our original system to be compliant with the specification and open sourcing [1] the code that's not custom to our application.