Privacy implications of loading JSON-LD context

[retog]

The privacy implications on loading JSON-LD's @context should be taken into account as this may leak some data to the server serving the context.

See: #73

[msporny]

@retog I added a section related to long lived identifier based correlation and listed credential-specific JSON-LD Contexts in a larger list of long lived identifiers that could be used to correlate. Please let me know if this addresses your issue, or if you would like me to elaborate on the JSON-LD Context attack more.

[retog]

@msporny: I don't think that correlating individuals via long-lived identifier is the issue here. But rather a breach of privacy when the context is dereferenced.

Example: Company A gives Alice a credential certifying that she is working for them. When applying for a new job at company B Alice presents that certificate. Company B will parse the JSON-LD and for that it will dereference the context which is served by a server of Company A. Now Company A can monitor the server's log and deduct from the request originating from Company B that Alice is applying for a job there.

[dlongley]

See: 04bed62#r26100232

[retog]

See: 04bed62#r26100232

For what? Does this go beyond long-lived identifiers?

[dlongley]

For what? Does this go beyond long-lived identifiers?

Yes, my comment addresses your example:

Example: Company A gives Alice a credential certifying that she is working for them. When applying for a new job at company B Alice presents that certificate. Company B will parse the JSON-LD and for that it will dereference the context which is served by a server of Company A. Now Company A can monitor the server's log and deduct from the request originating from Company B that Alice is applying for a job there.

Suppose, when company A gives Alice a credential, her digital wallet rewrites the context to use the default context or an embedded one. Then, when Alice presents the credential to company B, there be no context to deference that is served by Company A, i.e. no server at Company A will be hit, so no information will be leaked.

So, if my comment is incorporated into the privacy section, it will provide advice on how to mitigate the problem in the example you gave.

[agropper]

The issue of revocation intrudes. A’s revocation list is either hosted by A and hit by B or hosted on a public ledger where access by B is effectively anonymous. Adrian

On Wed, Dec 13, 2017 at 10:58 AM Dave Longley ***@***.***> wrote: For what? Does this go beyond long-lived identifiers? Yes, my comment addresses your example: Example: Company A gives Alice a credential certifying that she is working for them. When applying for a new job at company B Alice presents that certificate. Company B will parse the JSON-LD and for that it will dereference the context which is served by a server of Company A. Now Company A can monitor the server's log and deduct from the request originating from Company B that Alice is applying for a job there. Suppose, when company A gives Alice a credential, her digital wallet rewrites the context to use the default context or an embedded one. Then, when Alice presents the credential to company B, there be no context to deference that is served by Company A, i.e. no server at Company A will be hit, so no information will be leaked. So, if my comment is incorporated into the privacy section, it will provide advice on how to mitigate the problem in the example you gave. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#75 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIeYeOvBr9yu8VnE-sBBwHVzp6Z2I_pks5s__QkgaJpZM4P8XQ3> .

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/

[dlongley]

@agropper,

Yes, but revocation is a separate issue from this one. (Not that they aren't related, but we're tracking that differently and talking about it in different subsections in the spec.)