docs: add introduction to specification #2
Conversation
Just a draft for now, with some open questions to discuss.
spec/d16n-v1_0.adoc
Outdated
|
|
||
| // 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 |
There was a problem hiding this comment.
In the context of schools in Germany, this is not the case. The school has to get consent.
We just have to implement the data protection measures that satisfy the data controller (who we have a contract with).
spec/d16n-v1_0.adoc
Outdated
|
|
||
| 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. |
There was a problem hiding this comment.
That irritates me... Do the 2 sentences mean the same or is my brain still in monday morning mood?
spec/d16n-v1_0.adoc
Outdated
| // 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. |
There was a problem hiding this comment.
I think the hole paragraph is too complicated... What about something like
| 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. | |
| On the one hand, minors’ data is subject to special protection; on the other hand, it is essential for a teacher to be able to match students’ data to the actual individuals. |
There was a problem hiding this comment.
I even think we should drop that paragraph as it is already mentioned in the main readme
spec/d16n-v1_0.adoc
Outdated
| 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. |
There was a problem hiding this comment.
| 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 the Resolve API. |
spec/d16n-v1_0.adoc
Outdated
|
|
||
| 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.... |
There was a problem hiding this comment.
I would only mention the CSP header (see blow) and trust in competence of other developers implementing this...
spec/d16n-v1_0.adoc
Outdated
|
|
||
| // 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. !! |
There was a problem hiding this comment.
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.
cl3m0
force-pushed
the
add-intro-to-spec
branch
from
3061c3d to
387c5ab
Compare
|
With the risk of stepping on someone’s toes I cleaned up the introductions (picked draft 3 from README, condensed Spec Introduction). Please do not feel steamrolled... of course I am open for further discussions :) I really want to get this out of our way to gain speed on other projects. I will try to get an approval, land this and then ask for some other teams's evaluation. 🕊️ |
spec/d16n-v1_0.adoc
Outdated
| @@ -17,7 +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. | |||
There was a problem hiding this comment.
some sort formulation sounds somehow casual.
What do you think something using various ways. Something similar to:
It has become common to develop apps that incorporate single sign-on (SSO) in various forms to provide functionality in institutional or educational settings
?
spec/d16n-v1_0.adoc
Outdated
| // 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 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. |
There was a problem hiding this comment.
is typically used to identify that user by other users of the app
Do you mean rather to differentiate users ?
More like is typically used to identify that user FROM other users of the app ?
spec/d16n-v1_0.adoc
Outdated
|
|
||
| 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. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Just little commas and accents:
Through GDPR regulations minors data is subject to special protection ... ->
Through GDPR regulations, minors’ data is subject to special protection
spec/d16n-v1_0.adoc
Outdated
| 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. | ||
|
|
There was a problem hiding this comment.
It prescribes an automatic pseudonymisation
Do you mean depseudonymisation here?
| 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. |
There was a problem hiding this comment.
their data security or their data privacy , or its no difference in this context?
The spec wasn't really standing on its own, so let's add an introduction.
A bit of inspiration is taken from the introduction of RFC6749, The OAuth 2.0 Authorization Framework.
CX-979