feat: draft did:dns and did:web spec #7

Gozala · 2022-11-20T23:06:16Z

No description provided.

expede · 2022-11-21T00:26:14Z

ucan-dns+web.md

+## Pipelining dellegations
+
+[UCAN][] specification does not offer a way for two delegation chains to be pipelined into one. In our described scenario we have two delegation chains:
+
+1. `did:key:zAlice -> did:dns:w3.storage`
+2. `did:dns:w3.storage -> did:key:zService -> did:key:zRotation`
+
+From which we would like to construct a delegation of the capability delegated in (1) issued by the the (rightmost) audience in (2).
+
+```
+did:key:zAlice -> did:dns:w3.storage -> did:key:zService -> did:key:zRotation -> did:key:zAli
+```
+
+To accomplish this we propose that:
+
+- To issue delegation from `did:key:zRotation` with a valid proof chain (2) proving that `did:key:zRotation` has been delegated all capabilities from `did:dns:w3.storage`.
+- Embed proof chain (1) in `fct` as a verifable evidence that `did:dns:w3.storage` has been delegated capabilities for `did:key:zAlice`.


Interesting idea 💡 Certainly not against this in principle.

This may open up some new avenues for a confused deputy because it relies on any possible UCAN that you learn about in the rest of the network. Arguably this similar to using the ambient authority at the root of a delegation chain, but involves anyone that delegates to the forwarding principal even if they're offline. Aside from phishing, I'll have to think more on specific attacks.

Please note that it is implied that:

Every delegation is still checked for revocation.

did:dns:w3.storage resolution still occurs and if it resolves to different key validation will fail.

It is true that you can incorporate any of the delegation you can find on the network, but unless principal it was delegated to redelegated to you it's not possible to utilize it.

I think the more that I think about it, the more comfortable I am with it 👍

expede · 2022-11-21T00:33:11Z

ucan-dns+web.md

+          can: "*"
+        }
+      ]
+    },


If we decide to support pipelining, I wonder if we can put this in the prf field and just support this directly?

(Since this is "evidence", which is another name for a proof!)

I think we could, in fact I proposed that as option (2) in ucan-wg/spec#130. I mostly avoided here as it would directly violate principal alignment requirement

ucan-dns+web.md

hugomrdias

left some inline comments, i think the sections about full auth delegation and pipelining should be hoisted, there's examples that use those before they are defined. i was confused by that while reading.

hugomrdias · 2022-11-30T14:50:34Z

ucan-dns+web.md

+
+> There are other ways Alice could arrange delegation from `did:key:zAlice` to `did:key:zAli` with different tradeoffs. Evaluating them would be a good idea for a system designer, here we defining solution when no other option offers desired tradeoffs. -->
+
+To address described limitation we propose use of [`did:dns`] or [`did:web`] principals so that delegation from `did:key:zAlice` no loner is tied to a specific key. This would get us step further, but still we run into a problem, after key rotation delegation to `did:key:zAli` is no longer valid as the key that signed it is no longer the one did document resolves to.


Suggested change

To address described limitation we propose use of [`did:dns`] or [`did:web`] principals so that delegation from `did:key:zAlice` no loner is tied to a specific key. This would get us step further, but still we run into a problem, after key rotation delegation to `did:key:zAli` is no longer valid as the key that signed it is no longer the one did document resolves to.

To address described limitation we propose use of [`did:dns`] or [`did:web`] principals so that delegation from `did:key:zAlice` no longer is tied to a specific key. This would get us step further, but still we run into a problem where after a key rotation, the delegation to `did:key:zAlice` is no longer valid as the key that signed it is no longer the one the did document resolves to.

hugomrdias · 2022-11-30T14:53:20Z

ucan-dns+web.md

+
+To address described limitation we propose use of [`did:dns`] or [`did:web`] principals so that delegation from `did:key:zAlice` no loner is tied to a specific key. This would get us step further, but still we run into a problem, after key rotation delegation to `did:key:zAli` is no longer valid as the key that signed it is no longer the one did document resolves to.
+
+This specification describes solution to the second order problem by requiring that [`did:key`] that [`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.


Suggested change

This specification describes solution to the second order problem by requiring that [`did:key`] that [`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.

This specification describes a solution to the second order problem by requiring that the [`did:key`] that[`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.

hugomrdias · 2022-11-30T15:04:48Z

ucan-dns+web.md

+
+This specification describes solution to the second order problem by requiring that [`did:key`] that [`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.
+
+> Expample below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.


Suggested change

> Expample below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.

> Example below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.

hugomrdias · 2022-11-30T15:07:22Z

ucan-dns+web.md

+
+> Expample below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.
+>
+> This setup allows primary key (one that DID document resolves to) to be kept very safe e.g. on a piece of paper in safe deposit box, is it is only needed to delegate capabilities to `did:key:zService`. That key also is only used for rating keys and therefor can be stored securily e.g. in hardware key.


Suggested change

> This setup allows primary key (one that DID document resolves to) to be kept very safe e.g. on a piece of paper in safe deposit box, is it is only needed to delegate capabilities to `did:key:zService`. That key also is only used for rating keys and therefor can be stored securily e.g. in hardware key.

> This setup allows primary key (one that DID document resolves to) to be kept very safe e.g. on a piece of paper in safe deposit box, as it is only needed to delegate capabilities to `did:key:zService`. That key also is only used to rotate keys and therefor can be stored securely e.g. in hardware key.

hugomrdias · 2022-11-30T15:12:23Z

ucan-dns+web.md

+
+Above delegations MAY be embedded inside a relevant UCAN tokens, so that key in rotation at the moment of delegation MAY assume full authority over corresponding [`did:dns`][] or [`did:web`][] resource.
+
+> Example below illustrates `did:key:zRotation` delegating `did:key:zAli` capabilities derived from `did:dns:w3.storage` through `did:key:zService`. It embeds adove described delegation chain inside fact to provide a verifiable evidence that it can redelegate capbilities on `did:dns:w3.storage` bahalf


Suggested change

> Example below illustrates `did:key:zRotation` delegating `did:key:zAli` capabilities derived from `did:dns:w3.storage` through `did:key:zService`. It embeds adove described delegation chain inside fact to provide a verifiable evidence that it can redelegate capbilities on `did:dns:w3.storage` bahalf

> Example below illustrates `did:key:zRotation` delegating `did:key:zAli` capabilities derived from `did:dns:w3.storage` through `did:key:zService`. It embeds above described delegation chain inside facts to provide a verifiable evidence that it can redelegate capabilities on `did:dns:w3.storage` behalf

hugomrdias · 2022-11-30T15:19:37Z

ucan-dns+web.md

+
+[UCAN][] specification does not describe an ability to delegate authority over the resources delegating prinipcal MAY hold in the future. This makes it impossible for `did:dns:w3.storage` key to delegate capability that `did:key:zAlice` will delegate to it in the future.
+
+To overcome this limitation here we propose delegation with `att: []` and `exp: null` to be treated as delegation of complete authority:


this would need to be added to the ucan spec, right?

hugomrdias · 2022-11-30T15:20:09Z

ucan-dns+web.md

+
+## Pipelining dellegations
+
+[UCAN][] specification does not offer a way for two delegation chains to be pipelined into one. In our described scenario we have two delegation chains:


Suggested change

[UCAN][] specification does not offer a way for two delegation chains to be pipelined into one. In our described scenario we have two delegation chains:

[UCAN][] specification does not offer a way for two delegation chains to be pipelined into one. In our described scenario we have two delegation chains:

hugomrdias · 2022-11-30T15:20:42Z

ucan-dns+web.md

+1. `did:key:zAlice -> did:dns:w3.storage`
+2. `did:dns:w3.storage -> did:key:zService -> did:key:zRotation`
+
+From which we would like to construct a delegation of the capability delegated in (1) issued by the the (rightmost) audience in (2).


Suggested change

From which we would like to construct a delegation of the capability delegated in (1) issued by the the (rightmost) audience in (2).

From which we would like to construct a delegation of the capability delegated in (1) issued by the (rightmost) audience in (2).

hugomrdias · 2022-11-30T15:23:02Z

ucan-dns+web.md

+To accomplish this we propose that:
+
+- To issue delegation from `did:key:zRotation` with a valid proof chain (2) proving that `did:key:zRotation` has been delegated all capabilities from `did:dns:w3.storage`.
+- Embed proof chain (1) in `fct` as a verifable evidence that `did:dns:w3.storage` has been delegated capabilities for `did:key:zAlice`.


Suggested change

- Embed proof chain (1) in `fct` as a verifable evidence that `did:dns:w3.storage` has been delegated capabilities for `did:key:zAlice`.

- Embed proof chain (1) in `fct` as a verifiable evidence that `did:dns:w3.storage` has been delegated capabilities for `did:key:zAlice`.

hugomrdias · 2022-11-30T15:24:25Z

ucan-dns+web.md

+It can also be interpreted as `did:dns:w3.storage` stating to be "also known as"
+`did:key:zService` allowing it to delegate whatever `did:dns:w3.storage` CAN.
+
+## Pipelining dellegations


Suggested change

## Pipelining dellegations

## Pipelining delegations

Gozala and others added 4 commits November 20, 2022 15:05

feat: draft did:dns and did:web spec

e944b31

chore: move file

fe5a79e

last changed at Nov 20, 2022 3:04 PM, pushed by Irakli Gozalishvili

d161fc5

add badges

e609abc

Gozala requested a review from hugomrdias November 20, 2022 23:13

expede reviewed Nov 21, 2022

View reviewed changes

ucan-dns+web.md Show resolved Hide resolved

expede reviewed Nov 21, 2022

View reviewed changes

ucan-dns+web.md Show resolved Hide resolved

Gozala mentioned this pull request Nov 23, 2022

UCAN keymanagment #3

Closed

hugomrdias suggested changes Nov 30, 2022

View reviewed changes

Gozala mentioned this pull request Dec 7, 2022

services providers need to take delegations they can use storacha/w3up#265

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: draft did:dns and did:web spec #7

feat: draft did:dns and did:web spec #7

Gozala commented Nov 20, 2022

expede Nov 21, 2022 •

edited

Loading

Gozala Nov 21, 2022

expede Nov 21, 2022

expede Nov 21, 2022

expede Nov 21, 2022

Gozala Nov 21, 2022

hugomrdias left a comment

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022

hugomrdias Nov 30, 2022


		> There are other ways Alice could arrange delegation from `did:key:zAlice` to `did:key:zAli` with different tradeoffs. Evaluating them would be a good idea for a system designer, here we defining solution when no other option offers desired tradeoffs. -->

		To address described limitation we propose use of [`did:dns`] or [`did:web`] principals so that delegation from `did:key:zAlice` no loner is tied to a specific key. This would get us step further, but still we run into a problem, after key rotation delegation to `did:key:zAli` is no longer valid as the key that signed it is no longer the one did document resolves to.


		To address described limitation we propose use of [`did:dns`] or [`did:web`] principals so that delegation from `did:key:zAlice` no loner is tied to a specific key. This would get us step further, but still we run into a problem, after key rotation delegation to `did:key:zAli` is no longer valid as the key that signed it is no longer the one did document resolves to.

		This specification describes solution to the second order problem by requiring that [`did:key`] that [`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.

	This specification describes solution to the second order problem by requiring that [`did:key`] that [`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.
	This specification describes a solution to the second order problem by requiring that the [`did:key`] that[`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.


		This specification describes solution to the second order problem by requiring that [`did:key`] that [`did:dns`] and [`did:web`] resolve to MUST assume an ambient authority over (pre-resolution) DID, which it MAY delegate to other principals through standard UCAN delegation.

		> Expample below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.

	> Expample below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.
	> Example below illustrates `did:dns:w3.storage` delegating own resource to `did:key:zService`, which in turn redelegates it to `did:key:zRotation`.

	> This setup allows primary key (one that DID document resolves to) to be kept very safe e.g. on a piece of paper in safe deposit box, is it is only needed to delegate capabilities to `did:key:zService`. That key also is only used for rating keys and therefor can be stored securily e.g. in hardware key.
	> This setup allows primary key (one that DID document resolves to) to be kept very safe e.g. on a piece of paper in safe deposit box, as it is only needed to delegate capabilities to `did:key:zService`. That key also is only used to rotate keys and therefor can be stored securely e.g. in hardware key.


		Above delegations MAY be embedded inside a relevant UCAN tokens, so that key in rotation at the moment of delegation MAY assume full authority over corresponding [`did:dns`][] or [`did:web`][] resource.

		> Example below illustrates `did:key:zRotation` delegating `did:key:zAli` capabilities derived from `did:dns:w3.storage` through `did:key:zService`. It embeds adove described delegation chain inside fact to provide a verifiable evidence that it can redelegate capbilities on `did:dns:w3.storage` bahalf


		[UCAN][] specification does not describe an ability to delegate authority over the resources delegating prinipcal MAY hold in the future. This makes it impossible for `did:dns:w3.storage` key to delegate capability that `did:key:zAlice` will delegate to it in the future.

		To overcome this limitation here we propose delegation with `att: []` and `exp: null` to be treated as delegation of complete authority:


		## Pipelining dellegations

		[UCAN][] specification does not offer a way for two delegation chains to be pipelined into one. In our described scenario we have two delegation chains:

	From which we would like to construct a delegation of the capability delegated in (1) issued by the the (rightmost) audience in (2).
	From which we would like to construct a delegation of the capability delegated in (1) issued by the (rightmost) audience in (2).

	- Embed proof chain (1) in `fct` as a verifable evidence that `did:dns:w3.storage` has been delegated capabilities for `did:key:zAlice`.
	- Embed proof chain (1) in `fct` as a verifiable evidence that `did:dns:w3.storage` has been delegated capabilities for `did:key:zAlice`.

feat: draft did:dns and did:web spec #7

Are you sure you want to change the base?

feat: draft did:dns and did:web spec #7

Conversation

Gozala commented Nov 20, 2022

expede Nov 21, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hugomrdias left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

expede Nov 21, 2022 •

edited

Loading