-
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: account revamp #103
feat: account revamp #103
Conversation
w3-account.md
Outdated
1. To synchronizing namespace access across user agents they need to discover their [`did:key`] identifiers and level of access granted to them. | ||
2. Recovering access in case when all devices are lost becomes impossible. | ||
|
||
To address these issues, we propose the concept of an account. Account SHOULD have a human-meaningful identifier such as email address. We propose use of email addresses as account identifiers so that derived [`did:mailto`] can act as the [principal] in the [UCAN] delegation chain. This creates [principal] that can be used to aggregate capabilities and manage 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.
Account SHOULD have a human-meaningful identifier such as email address.
just curious, but why add this recommendation? is MAY sufficient? is there anything bad about a did:key
account?
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.
There is nothing wrong with aggregating capabilities under the did:key
principal, but I think calling it an account is just misleading. It just semantics, but I think they matter. For example you can not login as did:key
one because you can't expect user to type it in, but even they could we simply do not have flows to support that, if you'll try to request authorization from did:key
we will error.
So I think we should not call it account unless you can login with it.
|
||
## Roles | ||
|
||
There are several distinct roles that [principals] may assume in described specification: | ||
|
||
| Name | Description | | ||
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| Principal | The general class of entities that interact with a UCAN. Listed in the `iss` or `aud` field | |
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.
most other terms in this table get elaborated upon in a ###
section below. It could be helpful to eventually do the same for Principal
Co-authored-by: Alan Shaw <[email protected]> Co-authored-by: Benjamin Goering <[email protected]>
Based on #103 --------- Co-authored-by: Alan Shaw <[email protected]>
Based on #102