From 3061c3d7cb055d3ae7a5373399ff7bf75dea7427 Mon Sep 17 00:00:00 2001 From: cdiener Date: Mon, 25 Nov 2024 15:08:11 +0100 Subject: [PATCH] docs: my way of finishing it --- spec/d16n-v1_0.adoc | 23 +++++------------------ 1 file changed, 5 insertions(+), 18 deletions(-) diff --git a/spec/d16n-v1_0.adoc b/spec/d16n-v1_0.adoc index cd5bab8..e841977 100644 --- a/spec/d16n-v1_0.adoc +++ b/spec/d16n-v1_0.adoc @@ -17,31 +17,18 @@ This is written in the context of offering learning tools to children and their == Introduction -// TODO: write introduction - It has become common to develop apps that use some form of single sign-on (SSO) to deliver functionality in institutional or educational settings. -By using a single sign-on scheme, such as OpenID Connect, the third-party app often receives personal data, such as the full name, of a user during the authentication in order to present that user to other users of the app. -As the personal data is transferred to the server of the app, any logging, caching or storage of what is received must be treated with the appropriate level of data privacy safeguards. -When the server of the app receives this data, any logging, caching or storage it performs must be with the appropriate level of data privacy safeguards. - -In the education space, when building such apps for the school system this becomes problematic. +By using a SSO scheme, such as OpenID Connect, the third-party apps often receive personal data, such as the user's full name, during the authentication. This information is typically used to identify that user by other users of the app. However, transferring personal data to the app's server requires an appropriate level of data privacy safeguards, including proper logging, caching, and storage protocols. -// Is this true? Was it ever an alternative option for bettermarks to receive parental consent? Or is it in fact the case that we anyway get the parental consent - just for the reduced scope -// of "anonymised" usage. -Either each app needs to be given consent by parents to process their childrens data -or the identities of the children need to be hidden by some means of manual pseudonymisation. -That is, the app receives and can only show something like a nickname that each teacher must mentally, or using a crib sheet, translate into the names of their students. +In the education space, when building such apps for the school system this becomes problematic. Through GDPR regulations minors data is subject to special protection and needs to be hidden by some means of pseudonymisation. On the other hand, it is essential for a teacher to be able to match students' data to the actual individuals. -// Does data kept on the client need to be covered by a privacy policy? -D16N approaches this problem by specifying a way for a the client-side component of a third-party app to directly retrieve the names of users from the IDP. +D16N approaches this problem by specifying a way for a the client-side component of a third-party app to directly retrieve the users' names directly from the IDP. In this way, it should be possible to display recognisable names of students without exposing them beyond the bounds of a teacher's device. -It prescribes an automatic pseudonymisation and the issuance of an access token that enables the a client to look up the pseudonym in the metaphorical crib sheet, the Resolve API. +It prescribes an automatic pseudonymisation and the issuance of an access token that enables the a client to look up the pseudonym in the Resolve API. -// Should we warn people that any risks, as before, that were present on the frontend, e.g. malicious javascript, remain.... -// -// ¡¡ Or maybe this is where Clemens suggestion about CSP headers comes in. .i.e. preventing that the client can send the data to any malicious 3rd-party. !! +In addition it makes sense to use https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP[CSP] headers to ensure only whitelisted domains can be called to prevent that the client can send sensible data to any malicious 3rd-party. === Notational Conventions