6G/ Human Rights by (Protocol) Design - Make surveillance and profiling as expensive as possible…

From IIW

Human Rights by (Protocol) Design

Session Convener: Adrian G

Notes-taker(s): Hannah Sutor

Tags / links to resources / technology discussed, related to this session:



Slide 2, 4, 5

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Regulatory approach in EU is based on human rights - third slide is a link to the EU privacy directive

Message to take away: their framing is a human rights framing

Separation of concerns across levels -

  • Sign-in and signing
  • Requests for information
  • Storage of the result

This would accomplish human rights by design.

Scope along with purpose and identity become the request.

They are established at different points in time by different across.

Result is what gets presented to that resource server.

ACDC - graduated disclosure. “If you use my data, these are the restrictions i have on the usage of my data”

Delegation happens in what policies you put in to layer 2, which doesn’t store the data, only stores the policies:

SEE TABLE: See image(s) for these notes in the IIWXXXIV Book of Proceedings here:


Surveillance and profiling should be as expensive as possible…period. This isn’t something that is easily sold. How cheap do you make it to have secondary uses?

As long as you can keep an individual accountable, regardless of the delegation that has been introduced, consent is not achieved through prior blanket consent but through delegation.

Ricardian contract for requestor liability

Separate vocab SDO from state machine SDO

XAML PDP - PEP seperation

Q: Who is enforcing accountability?

A: In these protocols you lose the ability to have a firewall because now every single resource server , wallet element, etc is its own domain. One of the things we do to keep people accountable in the paper world is to use a notary. Very inexpensive away of authenticating a transaction. Taking it the other way, breaking the glass, is much more expensive. As long as on the average, notary is cheap, but holding them accountable is expensive, this is a separation of concerns. Can we introduce in the protocol a similar thing to a human notary?

Q: Is the whole “black box” of the way things work a concern for users trusting these systems?

A: Because of the visibility of software,

Q: When you say sign in and signing, is choosing session duration part of this? A: Yes, this would be part of it. ZTA - zero trust architecture. Scope and purpose. Scope has nothing to do with purpose. Scope is established by the resource owner. Ex: Scope is defined by patient (health record). System that stores the health record has it segmented and has tags for things that have sensitive data. Patient decides what to disclose based on purpose.

Q: Scope is about access to data?

A: Scope is which part of the record do you actually want? Any auth app has ways of handling scope.

Q: OAuth 2 scopes exist today. I’m imagining that eventually you’d want o be able to define even more granularity to try to convey intent. Is this where you’re heading?

A: No. We are dealing with 2 different domains:

  • Vocabulary issues
  • Protocol - who sends what to whom, when

Whiteboard Transcript:


  • Session duration (ZTA)
  • Request > Authorization Capability
  • Request components
    • credentials (who is accountable)
    • scope (all or some of the resource)
    • purpose (a GDPR human rights requirement)
  • Vocabulary interop vs. State machine interop
  • ACDC Graduated Disclosure (as serial requests)
  • No consent for secondary use, period
  • Notaries for accountability
  • AI > Federated Learning from personal data (education)
  • Ricardian Contract for requester liability
  • XACML, PDP and PEP
  • HIE of One demo project