Replies: 1 comment
-
Hi @mabels, Thanks for dropping in! It's always great to get feedback from the community — thanks :) You mentioned that you haven't had a chance to read the spec yet; it may be helpful to do that before we go into a ton of detail here. Drop a line in the thread when you've had a chance to do so, and we can chat more deeply. All the best! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I yesterday had the pleasure in Amsterdam to talk to some guys who said they are working on this spec.
btw I don't have there names ---
After some more thoughts there should be some extentions to the spec (which i did not read for now).
If there is any delegation there must be something in place which protects agaings the creation of endless loops. The sad thing about this is that we need to mutate the original object to detect the loop. This could lead to a chain of signings.
The other idea which i came up was why is there the need of delegation at all?
The mechanisum of granting rights should be only happing betweeen the authorizing and authorized partner, only this tuple
could agree on the given rights, if there is somebody between which get implicit also this right that leads to data leaks possibilities.
The authorizing party assumes that the authorized party should be the only who has the right to use the given rights.
My understanding of the in a decentralized system means we create some centralized things like these pair of two.
To mitigate that we need an other protocol which tunnels/transports/connectes these authoriziation pairs. But this does not
require any crypographic features and is so orders of magnitude simple to spec and implement.
Just some ideas out of the blue.
Thx for the beer
meno
Beta Was this translation helpful? Give feedback.
All reactions