From 614a9e24724491ba6b4ee1ab2ace591e7b8519d7 Mon Sep 17 00:00:00 2001 From: cakemanny Date: Wed, 20 Nov 2024 13:56:11 +0100 Subject: [PATCH 1/5] docs: add introduction to specification Just a draft for now, with some open questions to discuss. --- spec/d16n-v1_0.adoc | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/spec/d16n-v1_0.adoc b/spec/d16n-v1_0.adoc index 635f24f..5736d78 100644 --- a/spec/d16n-v1_0.adoc +++ b/spec/d16n-v1_0.adoc @@ -19,6 +19,28 @@ This is written in the context of offering learning tools to children and their // 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. + +// 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. + +// 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. +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. + +// Should we warn people that any risks, as before, that were present on the frontend, e.g. malicious javascript, remain.... + === Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in https://www.rfc-editor.org/rfc/rfc2119[RFC 2119]. From 0b50cdb2c9b980da773a2e6ae83993da21e0436f Mon Sep 17 00:00:00 2001 From: cakemanny Date: Thu, 21 Nov 2024 16:13:44 +0100 Subject: [PATCH 2/5] docs: add thought about adding suggestions around CSP headers --- spec/d16n-v1_0.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/spec/d16n-v1_0.adoc b/spec/d16n-v1_0.adoc index 5736d78..cd5bab8 100644 --- a/spec/d16n-v1_0.adoc +++ b/spec/d16n-v1_0.adoc @@ -40,6 +40,8 @@ In this way, it should be possible to display recognisable names of students wit 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. // 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. !! === Notational Conventions From 387c5ab196105320567d90e025dac53bf6660b15 Mon Sep 17 00:00:00 2001 From: cdiener Date: Mon, 25 Nov 2024 15:08:11 +0100 Subject: [PATCH 3/5] docs: my way of finishing it --- README.md | 47 +++++---------------------------------------- spec/d16n-v1_0.adoc | 23 +++++----------------- 2 files changed, 10 insertions(+), 60 deletions(-) diff --git a/README.md b/README.md index 581fc2e..24bacae 100644 --- a/README.md +++ b/README.md @@ -16,49 +16,12 @@ ### Why - - -#### _Draft 1_ - -Children have a lot to learn, so we want to offer them digital learning -experiences in the form of apps. - -In order to have a productive learning experience, -their teachers need to be able to identify the work of their students. -This is easiest when the teacher can see their students identified by the same -name they use in all apps and, in particular, the name used in the classroom. - -However, as app creators we have a special duty to protect the personal data -of children. The simplest way to do that is to not receive it. - -#### _Draft 2_ - -Per the [GDPR][GDPR], -children merit specific protection with regard to their personal. -The best way to protect that data is not to process it. - -We want to have a simple and common way for teachers to recognise their -students without putting their data at risk. - -[GDPR]: https://eur-lex.europa.eu/eli/reg/2016/679/oj - -#### _Draft 3_ - -As app creators we have a special duty to protect the personal data of -children. The simplest way to do that is to not receive it. +As app creators, we have a profound responsibility to safeguard the personal +data of children. The most effective way to protect it is to avoid collecting +it altogether. -We want to have a simple and common way for teachers to recognise their -students without putting their data at risk. +Our goal is to provide a simple and standardized method for teachers to identify +their students without compromising their data security. ### What 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 From f0c2fd9f2fc072efe02498d48cee18d1ffff13fb Mon Sep 17 00:00:00 2001 From: cdiener Date: Mon, 25 Nov 2024 16:45:39 +0100 Subject: [PATCH 4/5] docs: change position of arrow labels --- diagrams/connection.puml | 4 ++-- diagrams/connection.svg | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/diagrams/connection.puml b/diagrams/connection.puml index aa15a5c..1bb516d 100644 --- a/diagrams/connection.puml +++ b/diagrams/connection.puml @@ -8,8 +8,8 @@ rectangle RelyingParty as "Relying Party" #D9D9D9 { rectangle Server #85BCF0 } -IDP <-[#85BCF0]down-> Server : Authorization -IDP -[#FAC711]left-> Client : Clear Names +IDP "Authorization" <-[#85BCF0]down-> Server +IDP "Clear Names" -[#FAC711]left-> Client Client <-[#85BCF0]right- Server : Access Token legend diff --git a/diagrams/connection.svg b/diagrams/connection.svg index f57e055..c8e46a8 100644 --- a/diagrams/connection.svg +++ b/diagrams/connection.svg @@ -1 +1 @@ -Relying PartyClientServerIDPAuthorizationClear NamesAccess Token   Depseudonymized Area   Pseudonymized Area \ No newline at end of file +Relying PartyClientServerIDPAuthorizationClear NamesAccess Token   Depseudonymized Area   Pseudonymized Area \ No newline at end of file From e010677b8619d2f8b83a515ffcbbb5f7abb4779c Mon Sep 17 00:00:00 2001 From: cdiener Date: Tue, 26 Nov 2024 11:11:18 +0100 Subject: [PATCH 5/5] docs: last corrections --- README.md | 6 ++---- spec/d16n-v1_0.adoc | 17 +++++++++++------ 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 24bacae..fb2c05d 100644 --- a/README.md +++ b/README.md @@ -31,12 +31,10 @@ names without revealing those names to the creator of the app. We name it client-side depseudonymisation or simply d16n. -D16N refers to the Depseudonymisation process used in integrations, where +D16N refers to the depseudonymisation process used in integrations, where pseudonyms (abstract IDs) are exchanged instead of clear user names. This functionality allows a user's browser to communicate directly with IDP -servers to resolve these IDs into identifiable names. D16N enhances privacy by -ensuring that user identities remain protected during data exchanges, -particularly in educational contexts where sensitive information is involved. +servers to resolve these IDs into identifiable names. ### For Whom diff --git a/spec/d16n-v1_0.adoc b/spec/d16n-v1_0.adoc index e841977..11e7288 100644 --- a/spec/d16n-v1_0.adoc +++ b/spec/d16n-v1_0.adoc @@ -17,18 +17,19 @@ This is written in the context of offering learning tools to children and their == 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. +It has become common to develop apps that make use of single sign-on (SSO) in various forms to provide functionality in institutional or educational settings -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. +By using an 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 display that user to other users of the app. However, transferring personal data to the app's server requires an increased level of data privacy safeguards, including proper logging, caching, and storage protocols. -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. +In the education space, when building such apps for the school system this becomes problematic. +Through https://eur-lex.europa.eu/eli/reg/2016/679/oj[GDPR] regulations children's 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. 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 Resolve API. - -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. +It prescribes an automatic pseudonymisation and the issuance of an access token that enables the a client to look up the pseudonym in the an API implemented by the IDP, the xref:_the_resolve_api[Resolve API]. === Notational Conventions @@ -498,6 +499,10 @@ Clear Names should not be stored long-term on the End-User device. It may make sense to cache the Clear Names in the client for a short amount of time to avoid overburdening the IDP. We recommend that any caching of the Clear Names is expired when the End-User leaves the application. +=== Content Security Policy (CSP) Headers + +The RP should use https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP[CSP] headers to ensure only whitelisted domains can be called. +This prevents the client sending sensitive data to any unintended third party. === On-Site IDPs