Create a glossary and define terminology

[mibrand]

Based on existing sources, the terminology must be defined and published in a glossary to promote common understanding.

• OAuth Basic terms (SU, SP, RO, ...)
• PAR, RAR, ...
• Consent flow
• ...

[lwe]

@mibrand, not sure if this is the right ticket, or not, but I took upon the task to review the current glossary. At this point in time I don't have edit permissions and the Wiki doesn't allow me to create PR, so I'm using ticket comments for now. If given permissions I can easily just create a new revision in the Wiki page directly.

Generally, it's okay as-is, no changes necessary if you don't want to.

Minor changes

1. Customers / FI's customers: [...]

   To be aligned with other parts, I'd use FI's customers as term, as this is also used AFIAK by other pages.

2. Authorization Server: The server (i.e. the identity provider by the FI) [...]

   Resource Server: The server hosting the protected resources (i.e. by the FI) [...]

   Resource Owner: The entity (typically the end-user FI's customer) that [...]

   Client: The application (i.e. the TPP) [...]

   Just some more context and putting the OAuth terms into FAPI terminology.

Additions

While most terms are explained that need explaining, I'd introduce the following two additional terms:

1. Technologies and Standards > Grant Management: Allows the Resource Owner to manage access permissions to their data on a specific Resource Server, which they have created using one or more consent flow. The Resource Owner creates authorisations (implicitly in the consent flow) and can then delete, replace or update them as required in a standardised way.

   I've just used the definition from the main page, but I think it's sensible that way.

2. Technologies and Standards > CIBA (Client Initiated Backchannel Authentication): Describes a decoupled OpenID Connect authentication flow where the client initiates an authentication request, and the user authenticates on a separate device. Making it ideal for scenarios like smart speakers, call centers, or point-of-sale terminals.

   It's referenced in the main document, albeit as optional for now, however as we are discussing it in the main document I believe it would make sense to describe too.

Varia

I'd add links to all the relevant specifications too.