or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
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
Authorization scheme selection criteria
ie What features and use cases will an EDV authorization scheme need to support?
Criteria to start the conversation:
What language are we going to use to discuss Proof of Cryptographic Possession / Cryptographic Invocation (examples DPOP in OAuth2.0 vs ZCAP cryptographic invocation)
Delegation (multi-step delegation, with attenuation)
Structured Scopes (whatever authorization token we settle on should specify resource / action etc). (Like the structured scopes in auth.xyz)
Replication / Portability
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.
PROPOSAL: The authorization system MUST support decentralized delegation.
PROPOSAL: The authorization mechanism MUST rely on SOME FORM or cryptographic Proof of Possession
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.
PROPOSAL: The authorization system MUST include a mechanism for attenuated delegation of authority.
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
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)
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: