-
Notifications
You must be signed in to change notification settings - Fork 37
more detailed privacy considerations #244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
selfissued
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved, pending my suggestions being accepted.
Co-authored-by: Michael B. Jones <michael_b_jones@hotmail.com>
Co-authored-by: Joseph Heenan <joseph@heenan.me.uk>
Co-authored-by: Joseph Heenan <joseph@heenan.me.uk>
bc-pi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two minor nits on the latest text that I assume will be incorporated so approving.
jogu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! I agree with Brian's suggestions, and also suggested a few trivial grammar improvements.
|
The line breaks are somehow weird for this PR? Shouldn't for example
be in one line like this?
|
The markdown has been wrapped, which is inconsistent with the rest of the spec - albeit that doesn't make any difference to the generated HTML. |
The practice of putting an entire paragraph into a single source line results in MANY unnecessary merge conflicts. I support putting each sentence or long phrase into its own line - at least as we add new text. That said, line breaks should be at the end of sentences and/or complete clauses so that odd line breaks don't make it hard to search for multiple-word terms such as "authorization server". |
peppelinux
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved considering Brian's suggestions taken into consideration
c2bo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the suggestions of joseph & brian. Looks good to me apart from those minor changes
Co-authored-by: Brian Campbell <71398439+bc-pi@users.noreply.github.com> Co-authored-by: Joseph Heenan <joseph@heenan.me.uk> Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com>
| The Credential Issuer should obtain the End-User's consent before issuing Credential(s) | ||
| to the Wallet. It should be made clear to the End-User what information is being included in the | ||
| Credential(s) and for what purpose. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why lower-case should here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It used to be a MUST, we had a passionate discussion during the WG call based on a comment here and there were concerns with having a normative statements regarding consent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should all shoulds in this text be upper case SHOULD?
tplooker
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nits but in general big supporter of this PR, thanks!
Co-authored-by: Joseph Heenan <joseph@heenan.me.uk>
More detailed and thorough Privacy Considerations section for ID-1 inspired by implementation experience and a lot of related specifications. Not perfect, but should be good enough to convey how serious we are about privacy.
intended to replace #187.