generated from coulomb/repo-seed
Complete IDENTITY-WP-0003 corpus backfill and model refinement
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
This commit is contained in:
@@ -1,50 +1,114 @@
|
||||
# Activitypub Actors Followers
|
||||
# ActivityPub Actors and Followers
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for
|
||||
federated social actors, inboxes, and follower relationships.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Federated social graphs, actor identity, following/followers, and server-side
|
||||
account representation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
ActivityPub actors, inboxes, outboxes, followers, following, federation, and social identities.
|
||||
ActivityPub treats users as server-side actors with inboxes and outboxes. A
|
||||
person may have several actors across servers, mapping well to contextual
|
||||
identities and personas.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **Actor**: Activity Streams object (Person, Service, Group, Organization,
|
||||
Application) with `inbox`, `outbox`, `followers`, `following`, `liked`.
|
||||
- **Person actor**: human-associated actor on a federated server.
|
||||
- **Service / Application actor**: automated or app-mediated actor.
|
||||
- **Group actor**: collective actor with shared inbox/outbox.
|
||||
- **Follow activity**: actor A sends Follow to actor B; B may Accept or Reject.
|
||||
- **Followers / Following collections**: reverse-indexed social graph edges.
|
||||
- **preferredUsername**: handle local to the origin server.
|
||||
- **Actor ID (URL)**: globally unique actor URI, typically HTTPS profile URL.
|
||||
- **SharedInbox**: delivery optimization for addressing multiple actors.
|
||||
- **Public / followers-only addressing**: audience scoping for activities.
|
||||
- **WebFinger**: discovery of actor profile from `acct:user@domain`.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Actor | Server-hosted social entity with inbox/outbox; not necessarily one human. |
|
||||
| Person | Actor type for human-associated accounts. |
|
||||
| Follow | Directed activity establishing follower relationship. |
|
||||
| Follower | Actor who follows another actor. |
|
||||
| preferredUsername | Local handle on origin server. |
|
||||
| Actor ID | HTTPS URI identifying actor globally. |
|
||||
| Inbox / Outbox | Message endpoints for receiving/sending activities. |
|
||||
| Group (actor type) | Collective actor in ActivityPub sense. |
|
||||
| Service | Non-human automated actor type. |
|
||||
| acct: URI | Account identifier for WebFinger discovery. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **Actor is the primary social identity unit**, hosted on an origin server.
|
||||
- **One human may operate multiple actors** across servers (implicit, not
|
||||
standardized as same-person link).
|
||||
- **Following is a social subscription**, not membership or authorization.
|
||||
- **Actor ID is globally unique** within the fediverse namespace.
|
||||
- **Server is authority** for actor existence and deletion.
|
||||
- **Groups and Organizations are actor types**, not separate provisioning models.
|
||||
- **No standardized account linking** across actors for same natural person.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- ActivityPub **Actor** maps to **Actor** (Person → Natural Person association
|
||||
via Account/Profile on origin server).
|
||||
- **Person actor** implies **Natural Person** operator but actor ≠ person.
|
||||
- **Service/Application actor** maps to **Artificial Agent**.
|
||||
- **Group actor** maps to **Community** or **Group** collective actor.
|
||||
- **Follow** maps to **Following Relationship** (directed, social).
|
||||
- **preferredUsername** + domain maps to **Identifier** in server **Scope**.
|
||||
- **Actor ID (URL)** maps to global **Identifier**.
|
||||
- Multi-server actors per person support S02, S09, S14 without mandatory
|
||||
synonymity.
|
||||
- **followers-only** audience maps to Scope/audience boundary on Profile.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **Actor vs. User**: ActivityPub actor is server entity; apps say user.
|
||||
- **Person vs. Natural Person**: Person is actor type, not verified human.
|
||||
- **Group**: ActivityPub Group actor vs. LDAP/SCIM group vs. IAM group.
|
||||
- **Follow vs. Member**: following ≠ community membership unless separately defined.
|
||||
- **Account vs. Actor**: `acct:` suggests account, but actor is richer object.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| ActivityPub concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Actor (Person) | Actor + Profile + Account (on origin server) |
|
||||
| Actor (Service) | Artificial Agent + Service Account |
|
||||
| Actor (Group) | Community or Group collective actor |
|
||||
| Actor (Organization) | Organization collective actor |
|
||||
| Follow activity | Following Relationship |
|
||||
| Followers/Following collections | Relationship indexes |
|
||||
| preferredUsername | Identifier (local handle) |
|
||||
| Actor ID (URL) | Identifier (global) |
|
||||
| acct: URI | Identifier |
|
||||
| Origin server domain | Scope |
|
||||
| Inbox/Outbox | Operational endpoints (downstream) |
|
||||
| WebFinger | Discovery protocol (downstream) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should cross-server actors for one Natural Person require explicit Synonymity
|
||||
Assertion, or remain unlinked by default?
|
||||
- Does ActivityPub Organization actor type map to Organization or Community
|
||||
depending on moderation model?
|
||||
- How should moved-to / moved-from actor migration (if used) map to Identifier
|
||||
Binding supersession?
|
||||
- Should followers-only audience be a Profile visibility Scope or separate
|
||||
Relationship attribute?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- W3C ActivityPub — https://www.w3.org/TR/activitypub/
|
||||
- Activity Streams 2.0 — https://www.w3.org/TR/activitystreams-core/
|
||||
- WebFinger (RFC 7033) — https://datatracker.ietf.org/doc/html/rfc7033
|
||||
@@ -1,50 +1,113 @@
|
||||
# Foaf Agent Person Group Onlineaccount
|
||||
# FOAF Agent Person Group OnlineAccount
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Semantic vocabulary. FOAF (Friend of a Friend) RDF vocabulary for persons,
|
||||
agents, groups, and online accounts.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Semantic web social identity, person/agent distinction, and account
|
||||
representation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
FOAF Agent, Person, Organization, Group, OnlineAccount, and social relationship vocabulary.
|
||||
FOAF distinguishes persons, agents, organizations, groups, accounts, and
|
||||
membership-like properties — an early explicit separation of actor, account,
|
||||
and online presence.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **foaf:Person**: a person (human); may have name, homepage, depiction.
|
||||
- **foaf:Agent**: anything that can do things; superclass of Person, Organization,
|
||||
Group.
|
||||
- **foaf:Organization**: collective agent with members and name.
|
||||
- **foaf:Group**: collective agent with `member` property linking to agents.
|
||||
- **foaf:OnlineAccount**: account on a service; links via `accountServiceHomepage`
|
||||
and `accountName`.
|
||||
- **foaf:OnlineChatAccount / OnlineGamingAccount**: specialized account types.
|
||||
- **foaf:member**: agent belongs to group (inverse of Group membership).
|
||||
- **foaf:knows**: social acquaintance link between agents (not authorization).
|
||||
- **foaf:mbox / mbox_sha1sum**: email or hashed email identifiers.
|
||||
- **foaf:openid**: OpenID identifier for agent.
|
||||
- **foaf:Document / Image**: non-agent resources.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Person | Human being in FOAF sense. |
|
||||
| Agent | Anything capable of action; includes persons and collectives. |
|
||||
| Organization | Named collective agent. |
|
||||
| Group | Collective agent with explicit members. |
|
||||
| OnlineAccount | Presence on a service with account name. |
|
||||
| member | Membership link from group to agent. |
|
||||
| knows | Social network acquaintance between agents. |
|
||||
| accountName | Handle on a service. |
|
||||
| accountServiceHomepage | Service URL defining account namespace. |
|
||||
| mbox | Email identifier (often `mailto:` URI). |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **Agent is the root actionable type**; Person is a specialization.
|
||||
- **Person is explicitly human**, separate from accounts.
|
||||
- **OnlineAccount is not the person**; it is an account on a service linked
|
||||
to an agent.
|
||||
- **Groups and Organizations are agents** with member properties.
|
||||
- **Social knows is weak affiliation**, not trust or authorization.
|
||||
- **Identifiers (mbox, openid) are properties**, not first-class scoped objects.
|
||||
- **RDF graph allows multiple incomplete assertions** about same agents.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- FOAF **Person** maps closely to **Natural Person**.
|
||||
- FOAF **Agent** maps to **Actor**.
|
||||
- FOAF **Organization** / **Group** map to **Organization** / **Group**
|
||||
collective actors.
|
||||
- FOAF **OnlineAccount** maps to **Account** with service **Scope** defined
|
||||
by `accountServiceHomepage`.
|
||||
- **accountName** maps to **Identifier**.
|
||||
- **member** maps to **Membership Relationship**.
|
||||
- **knows** maps to **Affiliation Relationship** (social, weak).
|
||||
- FOAF is strong evidence for **P1** (actor root) and **P2** (person ≠ account).
|
||||
- Supports S01, S08, S09 with explicit person/account split.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **Agent vs. Artificial Agent**: FOAF Agent includes humans; canon Artificial
|
||||
Agent is non-human only.
|
||||
- **Group vs. Community**: FOAF Group is generic collective; community implies
|
||||
participation norms.
|
||||
- **OnlineAccount vs. Profile**: FOAF account is service presence; profile is
|
||||
broader presentation surface.
|
||||
- **knows vs. Following**: knows is bidirectional acquaintance; ActivityPub
|
||||
Follow is directed.
|
||||
- **mbox vs. Identifier**: mbox is contact + identifier; conflation risk.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| FOAF concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Person | Natural Person |
|
||||
| Agent | Actor |
|
||||
| Organization | Organization |
|
||||
| Group | Group |
|
||||
| OnlineAccount | Account |
|
||||
| accountName | Identifier |
|
||||
| accountServiceHomepage | Scope (service namespace) |
|
||||
| member | Membership Relationship |
|
||||
| knows | Affiliation Relationship |
|
||||
| mbox / openid | Identifier |
|
||||
| depiction / name | Profile attributes |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should FOAF OnlineAccount always imply Account, or sometimes Profile only?
|
||||
- How should `mbox_sha1sum` map for privacy-preserving synonymity (weak match)?
|
||||
- Does FOAF Group map to Group only, or also Community when informal?
|
||||
- Should knows remain Affiliation, or split into Following vs. acquaintance?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- FOAF vocabulary specification — http://xmlns.com/foaf/spec/
|
||||
- FOAF 0.99 RDF schema — http://xmlns.com/foaf/0.1/
|
||||
@@ -1,50 +1,112 @@
|
||||
# Schema Org Person Organization Membership
|
||||
# Schema.org Person Organization Membership
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Semantic vocabulary. Schema.org types and properties for Person, Organization,
|
||||
membership, and role-like affiliations.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Structured data about people and organizations, SEO/social graphs, and
|
||||
membership representation on the web.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Schema.org Person, Organization, memberOf, affiliation, and public entity metadata.
|
||||
Schema.org distinguishes persons, organizations, membership, employee roles,
|
||||
and affiliation properties — widely used for web-scale person/org modeling.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **Person**: living human; properties include `name`, `email`, `identifier`,
|
||||
`sameAs`, `affiliation`, `worksFor`, `memberOf`.
|
||||
- **Organization**: business, club, or other collective; `member`, `employee`,
|
||||
`department`, `subOrganization`, `parentOrganization`.
|
||||
- **OrganizationRole**: intermediate type linking person to organization with
|
||||
`roleName`, `startDate`, `endDate`.
|
||||
- **member / memberOf**: reciprocal membership between Person and Organization.
|
||||
- **employee / worksFor**: employment relationship properties.
|
||||
- **affiliation**: organization a person is affiliated with (looser than member).
|
||||
- **sameAs**: URL of related entity — often used for weak equivalence/synonymity.
|
||||
- **identifier**: PropertyValue or Text for external IDs.
|
||||
- **SportsTeam / PerformingGroup**: specialized Organization subtypes.
|
||||
- **ProgramMembership**: membership in a program with tier/benefits.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Person | Human being in structured data. |
|
||||
| Organization | Collective entity (company, club, NGO). |
|
||||
| memberOf | Person belongs to Organization. |
|
||||
| member | Organization has Person as member. |
|
||||
| employee | Person employed by Organization. |
|
||||
| worksFor | Inverse employment link. |
|
||||
| affiliation | Looser org association for Person. |
|
||||
| sameAs | Related/equivalent resource URL (weak linking). |
|
||||
| OrganizationRole | Named role with temporal bounds. |
|
||||
| subOrganization | Org hierarchy child. |
|
||||
| identifier | External ID for entity. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **Person means human** in schema.org intent.
|
||||
- **Membership and employment are properties**, not reified relationship objects
|
||||
(except OrganizationRole).
|
||||
- **sameAs is informal equivalence** between web resources, not verified identity.
|
||||
- **Organizations can nest** via subOrganization/parentOrganization.
|
||||
- **Roles can be typed** via OrganizationRole with dates.
|
||||
- **No authentication or authorization** semantics.
|
||||
- **Properties are multi-valued**; one person can have many memberships.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- Schema.org **Person** maps to **Natural Person**.
|
||||
- **Organization** maps to **Organization** collective actor.
|
||||
- **memberOf / member** map to **Membership Relationship**.
|
||||
- **employee / worksFor** map to **Affiliation Relationship** or employment
|
||||
specialization of Membership.
|
||||
- **affiliation** maps to **Affiliation Relationship** (looser).
|
||||
- **OrganizationRole** maps to **Role** relationship with temporal bounds.
|
||||
- **subOrganization** maps to structural relationship between Organization
|
||||
actors (child/parent).
|
||||
- **sameAs** maps to **weak Synonymity Assertion** between web resources —
|
||||
high conflation risk if treated as strong link.
|
||||
- **identifier** maps to **Identifier** PropertyValue.
|
||||
- Supports S03 (sub-orgs), S07 (informal groups as Organization subtypes), S08.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **Person vs. Profile**: schema.org Person is often used for public profile page.
|
||||
- **member vs. employee**: overlapping employment semantics; not always distinct.
|
||||
- **sameAs vs. Synonymity**: sameAs is SEO linking, not identity proofing.
|
||||
- **Organization vs. Community**: SportsTeam/PerformingGroup blur social vs. org.
|
||||
- **Role vs. OrganizationRole**: roleName may be job title or permission label.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| Schema.org concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Person | Natural Person |
|
||||
| Organization | Organization |
|
||||
| memberOf / member | Membership Relationship |
|
||||
| employee / worksFor | Affiliation or employment Membership |
|
||||
| affiliation | Affiliation Relationship |
|
||||
| OrganizationRole | Role + Membership with temporal bounds |
|
||||
| subOrganization | Organization hierarchy Relationship |
|
||||
| sameAs | Weak Synonymity Assertion (caution) |
|
||||
| identifier | Identifier |
|
||||
| ProgramMembership | Membership Relationship (program scope) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should sameAs ever promote beyond weak Synonymity without additional evidence?
|
||||
- Does OrganizationRole warrant a canonical temporal Relationship subtype?
|
||||
- How should ProgramMembership map vs. Community membership?
|
||||
- Should subOrganization be a distinct Relationship type or Organization attribute?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- Schema.org Person — https://schema.org/Person
|
||||
- Schema.org Organization — https://schema.org/Organization
|
||||
- Schema.org OrganizationRole — https://schema.org/OrganizationRole
|
||||
- Schema.org sameAs — https://schema.org/sameAs
|
||||
@@ -1,50 +1,108 @@
|
||||
# Webid Solid Profile
|
||||
# WebID and Solid Profile
|
||||
|
||||
## Source Type
|
||||
|
||||
TODO: Identify whether this is a standard, specification, product documentation, academic concept, architecture pattern, or implementation reference.
|
||||
Standard and ecosystem specification. WebID (W3C CG) for decentralized
|
||||
identifiers; Solid Protocol for user-controlled data pods and profiles.
|
||||
|
||||
## Domain
|
||||
|
||||
TODO: Classify the source domain.
|
||||
Decentralized identity-style profile discovery, user-controlled storage, and
|
||||
WebID-based identification.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
WebID and Solid profile concepts for decentralized/social identity and profile discovery.
|
||||
WebID/Solid support user-controlled profiles and decentralized identity-style
|
||||
profile discovery, relevant to persona, identifier, and data-sovereignty
|
||||
semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
TODO:
|
||||
- concept 1
|
||||
- concept 2
|
||||
- concept 3
|
||||
- **WebID**: HTTP(S) URI identifying an agent; dereferencing yields profile
|
||||
document (RDF).
|
||||
- **WebID profile document**: RDF description of agent with type, name,
|
||||
certificates, and links.
|
||||
- **Solid Pod**: user-controlled personal data store with access control.
|
||||
- **Solid Profile**: extended profile in pod with extended attributes and
|
||||
preferences.
|
||||
- **WebID-OIDC**: bridge binding OIDC authentication to WebID URI.
|
||||
- **Agent type in profile**: self-described person or organization.
|
||||
- **ACL (WAC / ACP)**: resource-level access control on pod resources.
|
||||
- **Type Index**: registry of resource types in a pod.
|
||||
- **Identity provider linkage**: OIDC issuer associated with WebID.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
TODO: Extract terms used by the source and note their source-specific meaning.
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| WebID | HTTP URI identifying an agent; profile at same URL. |
|
||||
| Profile document | RDF at WebID URI describing the agent. |
|
||||
| Pod | User-controlled storage space. |
|
||||
| Solid Profile | Profile data stored in pod. |
|
||||
| Agent | Entity described by WebID (person or org). |
|
||||
| WebID-OIDC | OIDC flow producing ID token with WebID claim. |
|
||||
| ACL | Access control on pod resources. |
|
||||
| Type Index | Discovery of pod resource categories. |
|
||||
| issuer | OIDC provider linked to WebID authentication. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
TODO: Capture assumptions made by the source about users, accounts, organizations, tenants, groups, roles, identities, relationships, or credentials.
|
||||
- **Identifier (WebID URI) is primary**; profile is dereferenceable description.
|
||||
- **User controls data placement** in pod, not only profile attributes.
|
||||
- **Agent self-describes** type (person/org) in RDF profile.
|
||||
- **Authentication can bind OIDC subject to WebID** via WebID-OIDC.
|
||||
- **Access control is resource-centric** on pod, separate from identity record.
|
||||
- **No central directory**; discovery via URI dereferencing.
|
||||
- **Multiple profiles/pods per person** possible across providers.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
TODO: Explain what this source suggests for the canonical identity model.
|
||||
- **WebID URI** maps to **Identifier** (globally dereferenceable).
|
||||
- **Profile document** maps to **Profile** with RDF attributes.
|
||||
- **Pod** maps to user-controlled **Scope** for data storage.
|
||||
- **Agent in profile** maps to **Actor** (Natural Person or Organization).
|
||||
- **WebID-OIDC binding** maps to **Synonymity Assertion** / **Identifier
|
||||
Binding** between OIDC `sub`+`iss` and WebID URI.
|
||||
- **ACL** maps to authorization projection on resources in pod Scope.
|
||||
- Supports S14 (pseudonymous/scoped identity), S02 (multiple profiles), user
|
||||
sovereignty goals from ResearchSeed.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
TODO: Record where this source uses terms differently from other sources.
|
||||
- **WebID vs. DID**: both decentralized identifiers; different ecosystems and
|
||||
resolution models.
|
||||
- **Profile vs. Account**: Solid profile is data surface; may not include
|
||||
login credentials on same system.
|
||||
- **Agent vs. Actor**: WebID agent is self-described entity; canon Actor is
|
||||
broader participation root.
|
||||
- **Identity vs. WebID**: developers equate WebID with whole identity.
|
||||
- **ACL vs. Authorization Principal**: pod ACL uses WebID URIs as agents.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
TODO: Map source-specific concepts to identity-canon candidate concepts.
|
||||
| WebID/Solid concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| WebID URI | Identifier |
|
||||
| Profile document | Profile |
|
||||
| Solid Pod | Scope (user-controlled data) |
|
||||
| Agent (in RDF) | Actor |
|
||||
| WebID-OIDC binding | Identifier Binding / Synonymity Assertion |
|
||||
| OIDC iss + sub | Scoped Identifier |
|
||||
| ACL agent | Authorization Principal (WebID URI) |
|
||||
| Type Index | Profile/discovery metadata |
|
||||
| Pod resource | Resource (downstream) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
TODO:
|
||||
- Question 1
|
||||
- Question 2
|
||||
- Should WebID URI be a distinct Identifier subtype vs. generic HTTP URI?
|
||||
- How should WebID-OIDC binding strength compare to OIDC pairwise sub (S14)?
|
||||
- Does pod Scope warrant a canonical "Data Scope" specialization?
|
||||
- Should Solid ACL remain purely authorization projection, or inform
|
||||
Relationship types for resource sharing?
|
||||
|
||||
## References
|
||||
|
||||
TODO: Add canonical URLs, RFC/spec identifiers, documentation links, and citation notes.
|
||||
- Solid Protocol — https://solidproject.org/TR/protocol
|
||||
- WebID 1.0 (community spec) — https://www.w3.org/2005/Incubator/webid/wiki/Identity_Providers
|
||||
- WebID-OIDC — https://solid.github.io/webid-oidc-spec/
|
||||
- Solid Access Control (ACP) — https://solidproject.org/TR/acl-spec
|
||||
Reference in New Issue
Block a user