-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: non-sudo authorization #49
Conversation
@@ -22,9 +22,19 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S | |||
|
|||
## Motivation | |||
|
|||
In web3.storage users may create (name)space by generating an asymmetric keypair and deriving [`did:key`] identifier from it. (Name)space owner (private key owner) can delegate some or all capabilities to other identifiers without anyone's permission, however managing keypairs across multiple agents and devices can be complicated. | |||
In web3.storage users may create (name)space by generating an asymmetric keypair and deriving [`did:key`] identifier from it. (Name)space owner (private key holder) can delegate some or all the (name)space capabilities to other identifiers without anyone's permission, however there are several UX challenges in this setup: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In web3.storage users may create (name)space by generating an asymmetric keypair and deriving [`did:key`] identifier from it. (Name)space owner (private key holder) can delegate some or all the (name)space capabilities to other identifiers without anyone's permission, however there are several UX challenges in this setup: | |
In web3.storage users may create (name)space by generating an asymmetric keypair and deriving [`did:key`] identifier from it. (Name)space owner (private key holder) can delegate some or all the (name)space capabilities to other identifiers without anyone's permission, however there are several User Experience challenges in this setup: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to appease this spellcheck failure
|
||
We propose [petname][] inspired approach that allows mapping cryptographic [`did:key`] identifiers to a memorable identity. This specification focuses on [`did:mailto`] identifiers, however approach is valid and can be extended to various other identifiers. | ||
1. Getting delegations synced across multiple user agents on multiple devices can prove challenging as agent would need discover each others DIDs without making user memorizing or typing them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. Getting delegations synced across multiple user agents on multiple devices can prove challenging as agent would need discover each others DIDs without making user memorizing or typing them. | |
1. Getting delegations synced across multiple user agents on multiple devices can prove challenging as agent would need to discover each others DIDs without making user memorizing or typing them. |
|
||
Authorization signature depends on the DID method of the principal. This specification only defines signatures for the [`did:mailto`] principal. Signatures for other DID methods is left undefined. | ||
|
||
### DKIM Signed Authorization |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Glad to see this! ❤️
The `./update` capability provides functionality roughly equivalent of [`Set-Cookie`] HTTP header. It allows capturing stateful information in the stateless UCAN delegations. | ||
|
||
Capability MAY include arbitrary session information in the `nb` along with `permit`. | ||
[Verifier] MUST ignored all other fields in the context of this specification, or put it differently MUST NOT impact authorization session handling. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Verifier] MUST ignored all other fields in the context of this specification, or put it differently MUST NOT impact authorization session handling. | |
[Verifier] MUST ignore all other fields in the context of this specification, or put it differently MUST NOT impact authorization session handling. |
Closing in favor of #50 |
🫣 preview