Skip to content
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

Closed
wants to merge 1 commit into from
Closed

feat: non-sudo authorization #49

wants to merge 1 commit into from

Conversation

Gozala
Copy link
Collaborator

@Gozala Gozala commented Feb 17, 2023

@@ -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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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:

Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[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.

@Gozala
Copy link
Collaborator Author

Gozala commented Feb 28, 2023

Closing in favor of #50

@Gozala Gozala closed this Feb 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants