Skip to content

update: links to contextualize this with w3account #52

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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dchoi27 wants to merge 2 commits into
base: main
Choose a base branch
from
Open

update: links to contextualize this with w3account #52

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
add26c0
update: links to contextualize this with w3account
dchoi27 Mar 1, 2023
6dadae5
Update w3-session.md
dchoi27 Mar 1, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions w3-session.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,17 +12,17 @@

# Abstract

Within the w3 family of protocols, users have the ability to manage access across namespaces through delegated [UCAN] capabilities using an [account]. However, this process can be daunting for an average user due to the use of unfamiliar user flows. To address this, we propose a complementary solution that can utilize a widely used email authorization flow.
Within the w3 family of protocols, users have the ability to manage access across namespaces through delegated [UCAN] capabilities using an [w3account]. However, this process can be daunting for an average user due to the use of unfamiliar user flows. To address this, we propose a complementary solution that can utilize a widely used email authorization flow.

## Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119](https://datatracker.ietf.org/doc/html/rfc2119).

# Introduction

An abstraction of an [account] provides a convenient method for sharing capabilities without the need to prearrange key exchange. While delegation to an [account] is represented with a standard [UCAN], delegation from an [account] requires the use of [DKIM signature]. However, generating such signatures requires users to send an email with a special subject line, which may not work well for many users.
An abstraction of an [w3account] provides a convenient method for sharing capabilities without the need to prearrange key exchange. While delegation to a [w3account] is represented with a standard [UCAN], delegation from a [w3account] requires the use of [DKIM signature]. However, generating such signatures requires users to send an email with a special subject line, which may not work well for many users.

To address this, we propose an alternative method for delegating capabilities from the [account] that uses a well-known email-based authorization flow that can be used alongside or instead of [DKIM signature]. In this document, we propose a protocol through which a user [agent] _(identified by a [`did:key`] identifier)_ can request a set of desired capabilities from a memorable [`did:mailto`] identifier through an intermediary that facilitates out-of-band user authorization. We also specify how the special `ucan/attest` capability can be utilized by supporting agents to establish authorization session.
To address this, we propose an alternative method (using an [Authorization Session Signature]) for delegating capabilities from the [account] that uses a well-known email-based authorization flow that can be used alongside or instead of [DKIM signature]. In this document, we propose a protocol through which a user [agent] _(identified by a [`did:key`] identifier)_ can request a set of desired capabilities from a memorable [`did:mailto`] identifier through an intermediary that facilitates out-of-band user authorization. We also specify how the special `ucan/attest` capability can be utilized by supporting agents to establish authorization session.

> 鈩癸笍 Note that while this specification focuses on [`did:mailto`] identifiers, this approach is valid and can be extended to various other identifiers.

Expand Down Expand Up @@ -297,6 +297,7 @@ Authorization sessions only apply to UCANs that have a [proof] linking to them.
[superuser]:https://en.wikipedia.org/wiki/Superuser
[DAG-JSON]:https://ipld.io/specs/codecs/dag-json/spec/

[w3account]:./w3-account.md
[Protocol Labs]:https://protocol.ai/
[Irakli Gozalishvili]:https://github.com/Gozala
[DKIM Signature]:./w3-account.md#domainkeys-identified-mail-dkim-signature
Expand Down