-
Notifications
You must be signed in to change notification settings - Fork 26
Terminology
This wiki is dedicated to the GNAP terminology. It is intended as an overview on the project status.
Feedback is most welcome but here is not the place for detailed discussions, which are to be handled through the IETF mailing list (for full proposals) or dedicated github issues (for specific terms/definitions). See the related issue #29 for more context.
The editors would expect that we can settle relatively quickly on the terms to be used in the spec, since it provides a conceptual basis. And we also need to get going on the core of the spec.
Discussed over the IETF mailing list
Various resources exist, as an example ISO has the habit of providing terminology, and there are even working groups dedicated to defining what is a good terminology ISO / TC37. In the ISO world, this has become even more important since the new high-level structure (there's always a section that contains common terms and core definitions). A non-official introduction.
Usually you have :
- a term
- a definition
- (optional) examples : useful to provide illustrative context
- (optional) sources : if reused from elsewhere, possibly with some adaptation to our context (then notes are useful)
- (optional) notes
Example : ISO 27001, section 3
The ISO rules for drafting definitions are in the ISO/IEC Directives, Part 2 (edition 2018): 16.5.6 Definitions The definition shall be written in such a form that it can replace the term in its context. It shall not start with an article (“the”, “a”) nor end with a full stop. A definition shall not take the form of, or contain, a requirement. Only one definition per terminological entry is allowed. If a term is used to define more than one concept, a separate terminological entry shall be created for each concept and the domain shall be included in angle brackets before the definition. Circular definitions, which repeat the term being defined, are not allowed.
In the IETF spec, we also tend to use short names (useful for diagrams). This can be an additional constraint, as it can be quite difficult to come with a unique name (ex: RP usually means "relying party" in our field, so we wouldn't use that acronym in a different way for our work, otherwise people would easily get confused).
We're listing some resources (related to AuthN and AuthZ) which might help. Please don't reinvent the wheel unless you really have to.
- privacy regulations, GDPR, CCPA, Canada, Brazil
- Canadian PCTF
- IAM index
- I'm not aware of any official terminology for OAuth2 or OpenID, but people/orgs have tried to clarify their understanding, see for instance Akamai although their interpretation seems strange
Feel free to suggest additional relevant sources.
We won't integrate new terms without first having a dedicated issue and consensus. Cf case of IS and see #133
server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (such as subject information).
application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.
Example: a client can be a mobile application, a web application, etc.
Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.
server that provides operations on protected resources, where operations require a valid access token issued by an AS.
subject entity that may grant or deny operations on resources it has authority upon.
Note: the act of granting or denying an operation may be manual (i.e. through an interaction with a physical person) or automatic (i.e. through predefined organizational rules).
natural person that operates a client instance.
Note: that natural person may or may not be the same entity as the RO.
characteristics related to a subject.
a data artifact representing a set of rights and/or attributes.
Note: an access token can be first issued to an client instance (requiring authorization by the RO) and subsequently rotated.
(verb): to permit an instance of client software to receive some attributes at a specific time and valid for a specific duration and/or to exercise some set of delegated rights to access a protected resource (noun): the act of granting.
right or attribute associated with a subject.
Note: the RO defines and maintains the rights and attributes associated to the protected resource, and might temporarily delegate some set of those privileges to an end-user. This process is refered to as privilege delegation.
protected API (Application Programming Interface) served by a RS and that can be accessed by a client, if and only if a valid access token is provided.
Note: to avoid complex sentences, the specification document may simply refer to resource instead of protected resource.
ability given to a subject to perform a given operation on a resource under the control of a RS.
person, organization or device.
statement asserted locally by an AS about a subject.