diff --git a/concept/concept.typ b/concept/concept.typ index 9fe8ff3..c192b43 100644 --- a/concept/concept.typ +++ b/concept/concept.typ @@ -42,15 +42,17 @@ // - Was soll mit der Anwendung gemacht werden? // - Welchen Vorteil haben Nutzende durch die Anwendung? -Die in diesem Projektkonzept beschriebene Anwendung soll eine einfache Anwendung zur Zeiterfassung für Werkstudenten sein. Für die Priorisierung der Entwicklung wird dabei in zwei Zielgruppen unterschieden. Die primäre Zielgruppe ist Studenten, die als Werkstudenten arbeiten und ihre Arbeitszeiten außerhalb eines von Arbeitgebern bereitgestellten Zeiterfassungssystem aufzeichnen wollen. Die erweiterte Zielgruppe sind selbständig Arbeitende, die ähnliche Bedürfnisse haben ihre Arbeitszeiten zu erfassen. +Die in diesem Projektkonzept beschriebene Anwendung ist als digitale Zeiterfassung für Werkstudenten konzipiert. Für die Priorisierung der Entwicklung wird zwischen einer primären und einer erweiterten Zielgruppe unterschieden. Zur primären Zielgruppe zählen Studierende, die als Werkstudenten tätig sind und ihre Arbeitszeiten außerhalb eines von Arbeitgebern bereitgestellten Zeiterfassungssystems dokumentieren möchten. Die erweiterte Zielgruppe umfasst selbstständig Tätige mit vergleichbaren Anforderungen an die Erfassung von Arbeitszeiten. +Die Wahl von Passkeys als Anmeldeverfahren orientiert sich an WebAuthn und an FIDO-Passkeys, die auf kryptografischen Anmeldungen ohne klassische Passwörter beruhen und als phishing-resistente Alternative zu passwortbasierten Verfahren etabliert sind @webauthn_l2 @fido_passkeys. -Für das Projekt wird sich in erster Linie auf die primäre Zielgruppe konzentriert und die erweiterte Zielgruppe wird in Betracht gezogen. -Nutzende haben durch die Anwendung die Möglichkeit nicht nur ihre Arbeitszeiten zu erfassen sondern auch Besitz von ihren Daten zu ergreifen und exportieren zu können ohne, dass sie in einem externen System in einer unzugänglichen Datenbank gespeichert sind. -Zudem müssen sie z.B. nicht dem Arbeitszeiterfassungssystem ihres Arbeitgebers vertrauen die Daten richtig zu speichern und haben somit eigene Nachweise für die geleistete Arbeitszeit. +Für das Projekt wird sich in erster Linie auf die primäre Zielgruppe konzentriert; die erweiterte Zielgruppe wird als sekundärer Anwendungsfall berücksichtigt. -Ziel des Projekts ist es nicht eine Anwendung zu entwickeln, die besonders viele Anwendungsbereiche abdeckt. Der Fokus liegt auf einer hohen funktionalen Dichte und Usability innerhalb eines reduzierten Feature-Sets (KISS-Prinzip - Keep It Simple, Stupid). +Die Anwendung soll es Nutzenden ermöglichen, ihre Arbeitszeiten zu erfassen, zu exportieren und dabei die Kontrolle über die eigenen Daten zu behalten, ohne auf ein externes, für sie nicht einsehbares System angewiesen zu sein. +Dadurch erhalten sie eine eigenständige Dokumentation der geleisteten Arbeitszeit und reduzieren die Abhängigkeit von der korrekten Verarbeitung durch Systeme Dritter. + +Ziel des Projekts ist nicht eine möglichst breit einsetzbare Lösung, sondern eine in ihrem Funktionsumfang bewusst begrenzte Anwendung mit hoher funktionaler Dichte und guter Gebrauchstauglichkeit. Dieses Vorgehen folgt dem Grundsatz eines reduzierten Systems mit geringer Interaktionskomplexität. //TODO wie viele Personen kann man durch die Anwendung potenziell erreichen //TODO Statistik über Bedürfniss nach Privatsphäre? @@ -68,8 +70,8 @@ Ziel des Projekts ist es nicht eine Anwendung zu entwickeln, die besonders viele // - Die wesentlichen Use-Cases der Anwendung // - Erstellen Sie ein einfaches Use-Case-Diagramm (es müssen keine CRUD-Use-Cases mo-delliert werden) // - Beschreiben Sie die Use-Cases kurz und knapp, so dass der Inhalt nachvollziehbar ist. -Im folgenden werden die funktionalen und nicht-funktionalen Anforderungen aufgeführt. Die wesentlichen Use-Cases der Anwendung werden im Kapitel Use-Cases erläutert. -Manche Anforderungen finden sich in beiden Kategorien wie Accessibility, da dieses zum einen als Compliance festgelegten Kriterien entsprechen muss und zum anderen aber auch nicht-funktional die Zugänglichkeit der Anwendung verbessert. +Im Folgenden werden die funktionalen und nicht-funktionalen Anforderungen aufgeführt. Die wesentlichen Use-Cases der Anwendung werden im Kapitel Use-Cases erläutert. +Einige Anforderungen erscheinen in mehreren Kategorien, etwa Barrierefreiheit, weil sie sowohl formale Konformitätskriterien als auch qualitative Anforderungen an die Nutzung betreffen. == Funktionale Anforderungen + Arbeitszeiterfassung @@ -82,7 +84,7 @@ Manche Anforderungen finden sich in beiden Kategorien wie Accessibility, da dies + Nutzende können Projekte erstellen. + Nutzende können Projekte bearbeiten. + Nutzende können Projekte löschen. - + Nutzende können Zeiten zu Projekten. + + Nutzende können Zeiten Projekten zuordnen. + Organisationen + Nutzende können Organisationen erstellen. + Nutzende können Organisationen bearbeiten. @@ -93,15 +95,15 @@ Manche Anforderungen finden sich in beiden Kategorien wie Accessibility, da dies + Nutzende können Nutzende aus Organisationen entfernen. + Nutzende können Nutzende für Organisationen anlegen. + Stopp-Start-Funktionalität - + Nutzende müssen ihre Arbeitszeiten stoppen und starten können und die Arbeitszeit wird automatisch aufgezeichnet. + + Nutzende müssen Arbeitszeiten starten und stoppen können; die Arbeitszeit wird dabei automatisch aufgezeichnet. + Benachrichtigungen - + Nutzende können regelmäßige Benachrichtigungen aktivieren, um sich an das Eintragen der Arbeitszeigen zu erinnern. + + Nutzende können regelmäßige Benachrichtigungen aktivieren, um an das Eintragen der Arbeitszeiten erinnert zu werden. + Die Anwendung soll in Deutsch und Englisch verfügbar sein. + Rechtliches (Compliance) + Barrierefreiheit (Accessibility): Die Anwendung soll WCAG 2.2 AA-konform sein. @w3c_wcag22 + WebAuthn/Sign-in - + Nutzende müssen sich mit einem Passkey registrieren können. - + Nutzende müssen sich über einen Passkey authentifizieren können. + + Nutzende müssen sich mit einem Passkey registrieren können @webauthn_l2. + + Nutzende müssen sich über einen Passkey authentifizieren können @webauthn_l2. + Nutzende können weitere Passkeys hinzufügen. + Nutzende können Passkeys löschen. + Hinzufügen, Editieren von Recovery-Email @@ -109,40 +111,39 @@ Manche Anforderungen finden sich in beiden Kategorien wie Accessibility, da dies == Nicht-Funktionale Anforderungen + Benutzerfreundlichkeit (Usability) - + Die Anwendung soll intuitiv und einfach zu bedienen sein. Dies bedeutet unter anderem, dass die Anwenung eine verständliche visuelle Hierarchie in der Benutzeroberfläche bietet und funktionale Anforderung mit minimalem Aufwand von Nutzenden erfüllt werden kann. - + Die Eingabe von Zeiten sollte mit möglichst wengig Tastatur-Eingaben erfolgen. + + Die Anwendung soll intuitiv und einfach zu bedienen sein. Dazu soll die Benutzeroberfläche eine klare visuelle Hierarchie aufweisen und typische Aufgaben mit möglichst geringem Interaktionsaufwand unterstützen. + + Die Eingabe von Zeiten sollte mit möglichst wenigen Tastatureingaben erfolgen. + Sicherheit (Security) + Daten werden verschlüsselt zwischen Client und Server gesendet. + Daten von Nutzenden sind sicher vor unauthorisierten Zugriffen geschützt. + Barrierefreiheit (Accessibility) - + Dies ist sowohl ein funktionales als auch eine nicht-funktionale Anforderung. Funktional: Compliance. Nicht-Funktional: "Accessibility beyond WCAG" - + In der funktionalen Anforderung soll die Anwendung den Rechtlichen Anforderungen entsprechen. + + Dies ist sowohl eine funktionale als auch eine nicht-funktionale Anforderung. Funktional: Konformität mit den geforderten Standards. Nicht-funktional: eine über Mindestanforderungen hinausgehende Zugänglichkeit. + + In funktionaler Hinsicht soll die Anwendung die rechtlichen Anforderungen erfüllen. + Fokus - + Die Anwendung soll sich auf die primären Ziele konzentrieren und diese qualitativ hochwertig umsetzen, anstatt möglichst viele Funktionen anzubieten. + + Die Anwendung soll sich auf die primären Ziele konzentrieren und diese qualitativ hochwertig umsetzen, anstatt einen möglichst breiten Funktionsumfang anzustreben. + Plattformunabhängigkeit + Die Anwendung soll auf verschiedenen Plattformen lauffähig sein. Dazu gehören Windows, macOS, Linux, iOS und Android. -+ Die Serverseitigen Komponenten der Anwendung sollen weitestgehend horizontal skalierbar sein. Auch wenn sie im Zuge des Projektes nicht horizontal skaliert werden. +- Die serverseitigen Komponenten der Anwendung sollen weitestgehend horizontal skalierbar sein, auch wenn im Rahmen des Projekts keine horizontale Skalierung umgesetzt wird. + Zuverlässigkeit (Reliability) - + Die Anwendung wird ausreichend für Demozwecke bereitgestellt und soll in diesem Umfang verfügbar, leistungsfähig genug sowie zuverlässig sein. + + Die Anwendung wird für Demonstrationszwecke bereitgestellt und soll in diesem Umfang verfügbar, leistungsfähig und zuverlässig sein. // - Klassendiagramm mit den Entitäten // - Erstellen Sie ein Klassendiagramm, in dem Sie die geplanten Entitäten mit ihren Beziehungen darstellen. // - Erläutern Sie kurz die Entitäten sowie deren Beziehungen zueinander. == Anforderungen außerhalb des Projektziels (Non-Goals) -Die Anwendung ist nicht für die Zeiterfassung von Organisationen gedacht sofern sie aus mehr als einem Arbeitnehmer bestehen. Es soll keine Verwaltung von Nutzenden für Organisationen geben. -Die Anwendung wird während des Projektes für Demozwecke bereitgestellt. Jedoch wird sie aus Kostengründen nicht in einer Form bereitgestellt, dass sie besonders hohen Andrang oder Leistungsfähigkeit oder Zuverlässigkeit bietet. Bereitstellung einer Produktionsumgebung ist außerhalb des Projektziels. Persistenz der Daten über lange Zeiträume ist ebenfalls nicht garantiert. +Die Anwendung ist nicht für die Zeiterfassung innerhalb von Organisationen mit mehr als einer arbeitenden Person vorgesehen. Eine Verwaltung von Nutzenden innerhalb von Organisationen ist daher nicht Teil des Projektumfangs. +Während des Projekts wird die Anwendung für Demonstrationszwecke bereitgestellt. Aus Kostengründen ist keine Produktionsumgebung vorgesehen; entsprechend sind hohe Last, langfristige Datenpersistenz und maximale Verfügbarkeit nicht Teil des Zielsystems. == Erweiterungen -Die Anwendung soll in Zukunft erweiterbar sein um Nutzenden in Zukunft ermöglichen, ihre Arbeitszeiten Projekten zuzuordnen. Dies ist jedoch nicht das primäre Ziel der Anwendung und wird gegebenenfalls in einem späteren Projekt ergänzt. +Die Anwendung soll in Zukunft erweiterbar sein, um Nutzenden das nachträgliche Zuordnen von Arbeitszeiten zu Projekten zu ermöglichen. Dies ist jedoch nicht das primäre Ziel der Anwendung und wird gegebenenfalls in einem späteren Projekt ergänzt. #pagebreak() = Anwendungsfälle (Use-Cases) Nutzende können mit der Anwendung ihre Arbeitszeiten aufzeichnen, exportieren, importieren, löschen und bearbeiten. -Eine Arbeitszeit ist einem Projekt zugeordnet und Nutzende können Projekte erstellen, bearbeiten und löschen. -Zudem können Nutzende ihre Arbeitszeiten exportieren und importieren. -Um die Erfassung von Zeiten zu vereinfachen können Nutzende einen Timer verwenden. Für diesen können sie optional Benachrichtigungen zur Erinnerung aktivieren. +Eine Arbeitszeit ist einem Projekt zugeordnet; Nutzende können Projekte erstellen, bearbeiten und löschen. +Zur Vereinfachung der Zeiterfassung können Nutzende einen Timer verwenden. Für diesen können sie optional Benachrichtigungen zur Erinnerung aktivieren. #figure( image("Use Case Diagram Time.svg", width: 50%), @@ -150,7 +151,7 @@ Um die Erfassung von Zeiten zu vereinfachen können Nutzende einen Timer verwend ) #pagebreak() -Nutzende können sich mit der Anwendung authentifizieren und sich mit einem Passkey registrieren. Passkeys können mit einem Label versehen werden um eine einfachere Wiedererkennung zu ermöglichen. Zudem können Nutzende Details zu ihren Passkeys einsehen wie der benutzte Authenticator. +Nutzende können sich mit der Anwendung authentifizieren und mit einem Passkey registrieren. Passkeys können mit einem Label versehen werden, um die Wiedererkennung zu erleichtern. Zudem können Nutzende Details zu ihren Passkeys einsehen, etwa den verwendeten Authenticator. #figure( image("Use Case Diagram Auth.svg", width: 50%), @@ -248,11 +249,11 @@ WebAuthnCredential "1" -- "1" WebAuthnAuthenticator : läuft auf > // - Reset links // - WebPush Subscription? -Im Zentrum der Anwendung steht die User-Entität. Sie wird genutzt um alle Daten mit einer Person zu verknüpfen. Nutzende haben in dieser Version der Anwendung noch keinen Namen, da dies an keiner Stelle benötigt wird. Bei System mit mehreren Nutzenden wäre ein Name zur Identifizierung der Nutzer untereinander nötig aber da Nutzende nicht miteinander interagieren wird hier auf die Minimalisierung von erfassten Daten bevorzugt. -Nutzende können ein oder mehrere Projekte erstellen unter denen Sie Zeiten erfassen können. Es besteht zu jeder Zeit mindestens ein Standardprojekt, das nicht gesondert angelegt werden muss, damit Nutzende sofort starten können Zeiten zu erfassen. -Für Timer besteht eine Entität damit Timer auch über Neustarts der Anwendung weiterhin bestehen können. Sie haben nur eine Startzeit, da sie bei Beendigung direkt gelöscht werden und in die erfassten Zeiten überführt werden. -Separat zu User existieren WebAuthn-User über eine 1:1 Verbindung, die mit einem Passkey (WebAuthn-Credential) verknüpft sind. Diese werden separat gehalten um die Authentifizierung und Autorisierung einfacher aus dem System ausgliedern zu können oder das ganze Modul eventuell zu löschen. -Um Passkeys besser wieder zu erkennen wird zusätzlich Metadaten wie Name und Icons von den verwendeten Authenticatoren gespeichert. +Im Zentrum der Anwendung steht die User-Entität. Sie dient dazu, sämtliche Daten einer Person zuzuordnen. In der aktuellen Version besitzt eine Person keinen Namen, da dieser an keiner Stelle benötigt wird. In einem System mit mehreren Nutzenden wäre ein Name zur gegenseitigen Identifikation sinnvoll; da Nutzende jedoch nicht miteinander interagieren, wird eine Minimierung der erfassten Daten bevorzugt. +Nutzende können ein oder mehrere Projekte erstellen, unter denen sie Zeiten erfassen können. Zu jedem Zeitpunkt existiert mindestens ein Standardprojekt, das nicht gesondert angelegt werden muss, damit die Zeiterfassung unmittelbar begonnen werden kann. +Für Timer existiert eine eigene Entität, damit laufende Timer auch über Neustarts der Anwendung hinweg erhalten bleiben. Sie speichern lediglich eine Startzeit, da sie bei Beendigung in die erfassten Zeiten überführt und anschließend entfernt werden. +Separat zur User-Entität existieren WebAuthn-User über eine 1:1-Beziehung, die mit einem Passkey (WebAuthn-Credential) verknüpft sind. Diese Trennung ermöglicht es, Authentifizierung und Autorisierung modular aus dem System auszugliedern oder das gesamte Modul später einfacher zu entfernen. +Zur besseren Wiedererkennung von Passkeys werden außerdem Metadaten wie Name und Icons der verwendeten Authenticatoren gespeichert. #figure( image("UML Class Diagram Entities.svg", width: 80%), @@ -263,29 +264,27 @@ Um Passkeys besser wieder zu erkennen wird zusätzlich Metadaten wie Name und Ic = Software-Architektur Durch die Anforderungen des Moduls an dieses Projekt soll für diese Software zwei Komponenten entwickelt werden, die in einer zentralisierten Server-Client-Architektur arrangiert sind. -Die erste Komponente ist eine HTTP JSON API, die den REST-Prinzipien nach Fielding folgt @fielding_rest. Für die Endpunkte zur Authentifizierung, Autorisierung und Hosting des Clients wird von diesen Prinzipien eventuell abgewichen werden müssen, da der API-Server auch die Rolle des Authentifizierungs-Servers erfüllt. +Die erste Komponente ist eine HTTP-JSON-API, die den REST-Prinzipien nach Fielding folgt @fielding_rest. Für Endpunkte zur Authentifizierung, Autorisierung und zum Ausliefern des Clients kann davon abgewichen werden, da der API-Server zugleich die Rolle des Authentifizierungsservers übernimmt. -Über die von der API bereitgestellten Endpunkte wird einer Client-Server-Architektur realisiert. Der Client ist eine Web-Anwendung, die die API-Endpunkte aufruft und die Daten aus der API abruft. Die API-Endpunkte werden von einem Server ausgeführt, der die Daten speichert und verarbeitet. -Zum Speichern der Daten kommt eine Datenbank wie eventuell PostgreSQL oder SQLite zum Einsatz. -SQLite würde sich anbieten, da dies das Deployment der Anwendung erleichtert, da SQLite nur eine persistente Datei im Dateisystem erfordert. Dahingegen benötigt PostgreSQL eine eigene Datenbankserverinstanz. -Zusätzllich wird für Authentifizierung über WebAuthn ein temporärer Speicher für Challenges benötigt, der mit einem Redis-Service umgesetzt werden kann. Um das Deployment der Anwendung simpel zu halten wird eventuell auf eine eigene Redis-Instanz verzichtet und stattdessen in der Server-Anwendung eine Tabelle zum Speichern der temporären Challenges eingebaut. Diese benötigt zudem einen regelmäßigen Background-Job um abgelaufene Challenges zu löschen damit die Tabelle nicht ohne Limitierungen zu groß wird. Ein weiterer Nachteil ist auch, dass die Zugriffszeiten auf diese Tabelle eventuell geringer sein werden als die Zugriffszeiten auf eine Redis-Instanz. Jedoch ist dies für das erste in diesem Projekt verkraftbar solange sie nur für Demonstrationszwecke verwendet wird und es das Deployment der Anwendung erleichtert. +Über die von der API bereitgestellten Endpunkte wird eine Client-Server-Architektur realisiert. Der Client ist eine Webanwendung, die die API-Endpunkte aufruft und Daten aus der API darstellt. Der Server verarbeitet und speichert die Daten. +Für die persistente Speicherung kommen wahlweise PostgreSQL oder SQLite in Betracht. SQLite ist für einen schlanken Projekt- und Deployment-Setup vorteilhaft, da es als dateibasierte Datenbank ohne separates Datenbankserversystem betrieben werden kann @sqlite_docs. PostgreSQL stellt demgegenüber ein vollwertiges Datenbanksystem mit separater Serverinstanz bereit @postgresql_docs. +Zusätzlich wird für die WebAuthn-Authentifizierung ein temporärer Speicher für Challenges benötigt. Zur Vereinfachung des Deployments kann dieser Speicher in einer Servertabelle umgesetzt werden, sofern ein externer Redis-Dienst vermieden werden soll. In diesem Fall ist ein regelmäßiger Hintergrundjob erforderlich, um abgelaufene Challenges zu entfernen und ein unkontrolliertes Anwachsen der Tabelle zu verhindern. -Damit Nutzende die Anwendung nutzen können wird eine Single-Page-Application (SPA) implementiert. Diese greift über die von der API bereitgestellten Endpunkte auf die Daten zu und bietet eine Schnittstelle mit der Nutzende mit der Anwendung interagieren können. -Die Anwendung kann über moderne Webbrowser geöffnet und genutzt werden um die Anforderung an die Verfügbarkeit auf verschiedenen Plattformen zu erfüllen. -Das Hosting der der SPA wird dabei auch von der API übernommen, da dies die eine Cookie-basierte Authentifizierung erleichtert und Cross Origin Resource Sharing (CORS) vermeidet, da die SPA sowie die API auf der gleichen Domain erreichbar sind. +Damit Nutzende die Anwendung verwenden können, wird eine Single-Page-Application (SPA) implementiert. Sie greift über die API auf die Daten zu und bildet die Benutzungsoberfläche der Anwendung. +Die Anwendung kann in modernen Webbrowsern auf unterschiedlichen Plattformen ausgeführt werden und erfüllt damit die Anforderung an Plattformunabhängigkeit. +Das Hosting der SPA erfolgt zusammen mit der API, da dies cookie-basierte Authentifizierung vereinfacht und Cross-Origin Resource Sharing (CORS) vermeidet, weil SPA und API unter derselben Domain erreichbar sind. = Wireframes -Der erste Screen, den Nutzende sehen, ist der Sign-in Screen. Hier werden sie begrüßt und können über einen Button direkt anmelden mit ihrem Passkey falls sie sich bereits registriert haben. -Alternativ können sie sich mit einem neuen Passkey registrieren. +Der erste Screen, den Nutzende sehen, ist der Sign-in-Screen. Dort können sie sich mit einem vorhandenen Passkey anmelden oder einen neuen Passkey registrieren. -Die beiden Optionen sind am unteren Rand des Screens zu finden damit sie leicht auf mobilen Geräten auszuwählen sind. Auf Desktop-Geräten sind sie weiter in der Mitte des Screens damit sie leichter gefunden werden können. +Die beiden Optionen sind am unteren Rand des Screens angeordnet, damit sie auf mobilen Geräten leicht erreichbar sind. Auf Desktop-Geräten werden sie mittiger platziert, damit sie schneller wahrgenommen werden. -Nach dem Sign-in sehen Nutzende ihre aktuellen Tage der Woche und erfasste Zeiten. Hier können sie Zeiten erfassen, bearbeiten und löschen. +Nach dem Sign-in sehen Nutzende ihre aktuellen Tage der Woche und erfasste Zeiten. Dort können sie Zeiten erfassen, bearbeiten und löschen. -Über ein Menü oben rechts können Nutzende sich abmelden oder zu ihren Passkey-Einstellungen gelangen. +Über ein Menü oben rechts können Nutzende sich abmelden oder zu ihren Passkey-Einstellungen wechseln. -Um schnell neue Zeiten zu erfassen oder einen Timer zu starten befindet sich in Reichweite des Daumens unten rechts ein Floating-Action-Button. +Um neue Zeiten schnell zu erfassen oder einen Timer zu starten, befindet sich unten rechts ein Floating-Action-Button in Daumenreichweite. #figure( @@ -294,7 +293,7 @@ Um schnell neue Zeiten zu erfassen oder einen Timer zu starten befindet sich in ) -Auf Desktop-Geräten verschiebt sich die Anzeige in die Breite und kann mehr Daten nebeneinander anzeigen. Zudem befinden sich der Floating-Action-Button und das Menü oben links, da dies der Leserichtung der Nutzenden folgt, schneller gefunden werden kann und Erreichbarkeit mit dem Daumen nicht mehr erforderlich ist, da vermutlich eine Maus genutzt wird. +Auf Desktop-Geräten wird die Darstellung breiter und kann mehr Informationen nebeneinander anzeigen. Zudem befinden sich der Floating-Action-Button und das Menü oben links, da dies der Leserichtung folgt und mit einer Maus schneller erreichbar ist. #figure( image("Wireframe Desktop.svg", width: 80%), diff --git a/concept/references.bib b/concept/references.bib index 140848c..d17a4b1 100644 --- a/concept/references.bib +++ b/concept/references.bib @@ -1,7 +1,7 @@ @online{w3c_wcag22, author = {W3C}, title = {Web Content Accessibility Guidelines (WCAG) 2.2}, - year = {2023}, + year = {2024}, url = {https://www.w3.org/TR/WCAG22/} } @@ -10,4 +10,39 @@ title = {Architectural Styles and the Design of Network-based Software Architectures}, year = {2000}, journal = {University of California, Irvine} +} + +@online{webauthn_l2, + author = {W3C}, + title = {Web Authentication: An API for accessing Public Key Credentials Level 2}, + year = {2021}, + url = {https://www.w3.org/TR/webauthn-2/} +} + +@online{passkeys_dev, + author = {Passkeys.dev}, + title = {Passkeys.dev}, + year = {2026}, + url = {https://passkeys.dev/} +} + +@online{fido_passkeys, + author = {FIDO Alliance}, + title = {Passkeys}, + year = {2026}, + url = {https://www.fidoalliance.org/passkeys/} +} + +@online{sqlite_docs, + author = {SQLite}, + title = {SQLite Documentation}, + year = {2026}, + url = {https://www.sqlite.org/docs.html} +} + +@online{postgresql_docs, + author = {PostgreSQL Global Development Group}, + title = {PostgreSQL 18.3 Documentation}, + year = {2026}, + url = {https://www.postgresql.org/docs/current/} } \ No newline at end of file