Model: Accounts and Users

[azaroth42]

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]

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]

:+1:

[no-reply]

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 #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 #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]

:+1: to the write-up above

[azaroth42]

Diagram of above whiteboard:

[azaroth42]

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

[anarchivist]

@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]

Closed by #54