search

decentralized-identity / decentralized-web-node

Decentralized data storage and message relay for decentralized identity and apps.
https://identity.foundation/decentralized-web-node/spec/
Apache License 2.0
402 stars 79 forks source link

Section 10: Access & Permissions #139

Open alanhkarp opened 2 years ago

alanhkarp commented 2 years ago

This section is empty. Provide content or delete.

andorsk commented 1 year ago

Is this still an issue? https://identity.foundation/decentralized-web-node/spec/#permissions

alanhkarp commented 1 year ago

Section 10.4.1 Permission Request

The object MAY contain a delegation property, and its value MUST be a boolean, wherein true indicates the issuing party is allowing the grantee the ability to delegate the capability. A value of false or omission of the property MUST be evaluated as false, and indicates the grantee MUST NOT be allowed to delegate the capability.

Attempts to enforce "Do not delegate" are always a bad idea. If you can't delegate when you need to, you will share credentials, a private key in this case. The result is a system that is both less secure and harder to use. What does make sense is a "Please do not delegate" property. In that case, you may want to include a description of why the request is being made, and a section in a delegation from it explaining why the delegation was done.

Consider the case where you hold a powerful capability and want a program running on your behalf to use it. You can't attenuate the permissions in the capability. Here you can assume you are not violating a "Please do not delegate" request.

alanhkarp commented 1 year ago

Section 10.4.2 PermissionsGrant

The object MAY contain a sharedAccess property, and its value MUST be a boolean, wherein true indicates the requesting party wants the ability to use the permission against any object or data that aligns with the capability’s definition, regardless of which entity created the object or data. A value of false or omission of the property MUST be evaluated as false, and indicates the requesting party only needs the ability to invoke the permission against objects or data it creates.

A capability is an unforgeable, transferrable permission to use the thing it designates. A capability with the sharedAccess property does not designate a specific thing. Hence, it is not a capability and should not be used to authorize a request. However, it can be used to create a delegation from it that designates a specific object or data. Going further, it is good practice for a capability to specify a single authorized operation, e.g., a read/write capability should be attenuated to either read or write before being used.

alanhkarp commented 1 year ago

I don't understand why you would ever have an unsigned message object.

alanhkarp commented 1 year ago

Isn't the publish property a "Please do not publish"?

andorsk commented 1 year ago

@alanhkarp we'll discuss this over the next DIF call (2 weeks from now) and respond in this thread post discussion.