owned this note changed 4 years ago
Linked with GitHub

Secure Data Storage WG Agenda - Thu Sep 17, 2020

Current Spec | Issues | Meeting Recordings/Transcripts

The IPR policy requires that you can only make substantive contributions if you sign the IPR Release Form. Please follow the instructions at https://dif.groups.io/g/sds-wg/wiki/Home

Agenda

  1. IPR Reminder
  2. Introductions and Re-Introductions
  3. Authorization: Criteria Selection
  4. (if time) Issue Review

Authorization scheme selection criteria
ie What features and use cases will an EDV authorization scheme need to support?

Criteria to start the conversation:

  1. What language are we going to use to discuss Proof of Cryptographic Possession / Cryptographic Invocation (examples DPOP in OAuth2.0 vs ZCAP cryptographic invocation)

    • need to agree on the language
    • need to agree on if it's a required selection criteria
  2. Delegation (multi-step delegation, with attenuation)

    • need a good clear example of why delegation might be useful
  3. Structured Scopes (whatever authorization token we settle on should specify resource / action etc). (Like the structured scopes in auth.xyz)

    • as opposed to: OAuth2's flat freeform scopes
  4. Replication / Portability

    • (if my Vault is replicated, so should the permissions)

Call Notes on Criteria:

Criteria One:
Some kind of cryptographic binding for the authorization token. (ie Not just a bearer token.)

Manu: Let's avoid using spec-specific language. Instead, lets describe what it does.
Orie: "does the caller need a private key"
Dave Longley: "each authorization requires the use of cryptographic material"
Tobias: "there is a cryptographic binding established to the authorised client which must be proved when the client invokes / makes a requests/proved/invoked ..?"

PROPOSAL: The authorization system MUST NOT support decentralized delegation.

  • a bunch of -1s in chat.

PROPOSAL: The authorization system MUST support decentralized delegation.

  • ~9 +1s

PROPOSAL: The authorization mechanism MUST rely on SOME FORM or cryptographic Proof of Possession

  • 8 +1s

Definition of 'Attenuation'

Andreas Freund: attenuate = reduced in force, effect, or physical thickness.
Dave Longley: an example: you have the authority to read and write an EDV document, and you can delegate the ability just to read to someone else
Orie: (gives classic car example)

PROPOSAL: The authorization system MUST NOT include a mechanism for attenuated delegation of authority.

  • all -1s

PROPOSAL: The authorization system MUST include a mechanism for attenuated delegation of authority.

  • all +1s

Dave Longley: We should probably put in reasonable limits on that attenuation ability.

PROPOSAL: The authorization system MUST NOT require integrity checking of HTTP requests

  • all -1s

PROPOSAL: The authorization system MUST integrity check all parts of the HTTP request that are critical to the security of the operation being performed. (relevant headers and body)

  • all +1s

For this call, you are encouraged to turn your video on. This is a good way to build rapport given we are a new group getting to know each other as we begin our work.

Attendees:

  • Orie Steele
  • Tobias Looker
  • Adrian Gropper
  • Dave Longley
  • Michael Shea
  • Evan Tedesco
  • Martin Riedel
  • Manu Sporny
  • Andreas Freund
  • Dmitri Zagidulin
Select a repo