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

[did-configuration] Company vs Customer / Account DIDs #7

Closed
OR13 opened this issue Aug 16, 2019 · 4 comments
Closed

[did-configuration] Company vs Customer / Account DIDs #7

OR13 opened this issue Aug 16, 2019 · 4 comments
Assignees

Comments

@OR13
Copy link
Contributor

OR13 commented Aug 16, 2019

Its possible to use the .well-known/did-configuration to expose DIDs for the domain, that are "Company" DIDs, but its also possible for it to be "Customer" DIDs, or user DIDs...

The question here is about providing guidance on what kinds of DIDs should be associated with a domain.

It seems like we should take an authoritative stance, that this uri is not to be used for customer or user account/ user agent / wallet DIDs.

For an analogy, if we're talking about twitter:

https://twitter.example.com/.well-known/did-configuration

Would hold DIDs for the company twitter, but NOT twitter users.

@OR13
Copy link
Contributor Author

OR13 commented Aug 16, 2019

I suggest we add some specific language to the spec advising domain controllers to not automatically register DIDs on behalf of domain users here.

If that is a desirable feature, I believe it should be exposed using webfinger instead, since that is a well known uri that is built for discovering users of a domain.

@peacekeeper
Copy link
Member

+1 domain controllers must not automatically register DIDs on behalf of domain users.

The spec can still be used for person DIDs if you "own" (=rent) your own (sub-)domain name, e.g. alice.name or alice.company.com.

@csuwildcat
Copy link
Member

I agree with this, and will add a note to the spec for guidance.

@csuwildcat
Copy link
Member

This has been added several places in the spec. Closing, but feel free to add a PR if further text additions are desired.

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

No branches or pull requests

3 participants