Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
67 changes: 67 additions & 0 deletions terminology.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,67 @@
# Terminology

## User

Person identified with [WebID](https://www.w3.org/2005/Incubator/webid/spec/identity/).
Assumed as trusted unless explicitly called **malicious user**.

## WebID Profile

Document resulting from dereferencing WebID [as specified](https://www.w3.org/2005/Incubator/webid/spec/identity/).
No assumptions made about where it stays hosted.

## Resource Server (RS) [RFC6749]

The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

## Solid detail
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the subtitle Solid detail is a bit weird. I thought for a while reviewing this that this was a new term that you wanted to introduce. Given that there is only one sentence below perhaps there is no need to have a subsection.
Can't think of a better title right now...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i made it wrong header level, but maybe i'll just make it a paragraph prefix instead to avoid confusion


Server hosting resources protected with [Web Access Control](https://github.com/solid/web-access-control-spec).

## Resource Owner [RFC6749]

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

### Solid detail

User with [`acl:Control`](https://github.com/solid/web-access-control-spec#aclcontrol) access mode.
No assumptions on relationship to Resource Server hosting it.

## Authorization Server (AS) [RFC6749]

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

## OpenID Provider (OP) [OpenID.Core]

OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User.

### Solid detail [WebID-OIDC]

WebID Profile can link to it using [`solid:oidcIssuer`](https://github.com/solid/webid-oidc-spec#issuer-discovery-from-webid-profile) predicate.

## Storage

LDP container hosted on Resource Server,
WebID Profile can link to it using [`space:storage`](https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md#storage-discovery). Resource Server can host multiple storages.

## Client [RFC6749]

An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

## Client Software [RFC7591]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is too general. Client Software should not be a word that is tied to a particular authentication protocol.

I suggest OAuth client instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This term comes directly from RFC7591, I think unless we find emerging consensus on not building on OAuth2 we should keep our terminology closely aligned. BTW I don't think I've seen it used anywhere in our conversations so it also doesn't seem to collide with existing use by someone meaning something else.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RFC7591 is the OAuth Dynamic Client spec. So it makes sense that it uses the general term "Client Software" within the context of that spec. If you were to use that term in say the Internet Identity Workshop it would be very confusing, or look like you are choosing ahead of time what is being proposed.

There are many ways of doing identity, and we should not tie ourselves to one protocol through the vocabulary we use. This does not mean giving up on OAuth, it just makes it possible to speak about the other Identity protocols we are using or have been discussing such as WebID, HttpSig's keyId, or Credentials.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the overall context of these documents, the phrase "Client Software" is unlikely to always and only refer to "OAuth 2.0 Client Software", so I think it would be better to use the qualified label when the qualified meaning is intended.

In other words, change ## Client Software [RFC7591] to ## OAuth 2.0 Client Software [RFC7591]


Software implementing an OAuth 2.0 client.

## Client Instance [RFC7591]

A deployed instance of a piece of client software.

## References
* [RFC6749](https://tools.ietf.org/html/rfc6749) The OAuth 2.0 Authorization Framework
* [RFC7591](https://tools.ietf.org/html/rfc7591) OAuth 2.0 Dynamic Client Registration Protocol
* [OpenID.Core](https://openid.net/specs/openid-connect-core-1_0.html#Terminology) OpenID Connect Core 1.0
* [WebID-OIDC](https://github.com/solid/webid-oidc-spec) WebID-OIDC Authentication

------------

TODO: reconcile with https://github.com/solid/webid-oidc-spec#decentralized-authentication-glossary