Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Model: Accounts and Users #6

Closed
azaroth42 opened this issue Sep 21, 2015 · 8 comments
Closed

Model: Accounts and Users #6

azaroth42 opened this issue Sep 21, 2015 · 8 comments
Assignees

Comments

@azaroth42
Copy link
Contributor

Should model the following:

  • Accounts
  • Agents: People / Organizations / Software
  • Roles
  • Events
  • Acting onBehalfOf another Person or Organization

Use cases:

  • Self-Submission
  • Annotations (Comments, Tags, Reviews, etc)
  • Access Rights
  • Recommender systems
  • Usage tracking / history
  • Personalization
@azaroth42
Copy link
Contributor Author

Ping @hybox/drs-team:

Unless you have further guidance, we'll run with Accounts being a required model and linked to Persons (or other Agents like Organization or SoftwareApplication). Please let us know any requirements, otherwise we'll take a best guess :)

@hannahfrost
Copy link

👍

@no-reply
Copy link

This image is a sketch of the Agent, Account, and ACL models. Note that the ACL/Auth relationships (the bottom right) is slightly flattened in the drawing. The full structure is as documented at WebACL.

In summary:

  • foaf:Accounts are used for sign-on/identification; they are sioc:account_of (? see Select inverse properties #30) a foaf:Agent.
    • We model accounts for completeness, but make no assumption that they will be implemented as repository objects. They may be managed by a database, etc...
  • Agents may be People, Groups, Organizations. They represent real entities.
    • We identified and verified the use case that an authorization Agent and a metadata Agent (e.g. a dc:creator) may be the same person, so we make no distinction between these Agent types.
  • Agents may be org:memberOf (? see Select inverse properties #30) any foaf:Group.
  • Groups may be for authorization purposes only, or used for metadata.
    • Do we have use cases for authenticating on groups that are used in a metadata context (e.g. an academic department?; cc: @hybox/drs-team ).
  • An Authorization has either an acl:agent which is an Agent, or an acl:agentClass which is a Group.

@azaroth42, @awoods we talked a bit about the IP authentication use case: do we want to consider the possibility of using acl:trustedOrigin for these kinds of cases?

@azaroth42
Copy link
Contributor Author

👍 to the write-up above

@azaroth42
Copy link
Contributor Author

Diagram of above whiteboard:
hybox-acls

@azaroth42
Copy link
Contributor Author

This issue can be closed when the above documentation is available in models/permissions.md.

@anarchivist
Copy link
Member

@azaroth42, @awoods we talked a bit about the IP authentication use case: do we want to consider the possibility of using acl:trustedOrigin for these kinds of cases?

acl:trustedOrigin doesn't exist in the BasicAccessControl vocabulary yet. I'm creating a new issue to track IP-based auth.

@anarchivist
Copy link
Member

Closed by #54

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants