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

Determine schema for method entry controls #425

Open
jandrieu opened this issue Mar 21, 2022 · 1 comment
Open

Determine schema for method entry controls #425

jandrieu opened this issue Mar 21, 2022 · 1 comment

Comments

@jandrieu
Copy link
Contributor

jandrieu commented Mar 21, 2022

Currently there are several DID Method entries with multiple contact names, but no examples with several contact emails.

I'd like some clarification about how multiple "controllers" should be represented and what that means.

My preference would be for a single email that is the sole authority and that should be a normative restriction. This means the Contact Name is non-controlling: it designates how to refer to the Contact, without regard to the legal qualifications of whoever might so be named.

NOTE

One alternative would be to make the contact name the legal controller with email as one authentication mechanism. This is probably clearer from a legal standpoint, but just raises more questions about the supposed relationship between the ContactName and the email used for authentication. It also doesn't answer the question of how to handle unincorporated collaborations, such as BTCR.

If we allow multiple emails, we need to decide if all emails must concur on updates or if any one of the emails is valid or some other logic (m of m, 1 of m, or n of m. We also need to decide if those are going to be listed in an array or, like Contact Email today, a comma separated list is acceptable. My preference is to use an array so parsing just uses JSON semantics.

Note

As of today, we have no methods that list multiple email addresses, but several that list multiple Contact Names.

For now, my recommendation is to require one and only one email address and that is the sole mechanism for authentication.

My second recommendation would be to also allow specifying a DID for authentication, to avoid the dependency on email. This would be harder, but is at least aligned with a single omnipotent authentication mechanism. I could also see allowing both a DID and an email, in case the relying party cannot support the DID method, they could use the email as fallback.

I will also note that eventually we probably want to separate legal ownership from the authentication of that legal entity. However, that way lies dragons, just from the sheer number of different decisions that will need to be made to address that properly.

For now, I'm just trying to get some guidance for what these JSON entries mean when there are multiple email addresses and/or multiple contact names.

@jandrieu
Copy link
Contributor Author

Correction. There is at least one entry with multiple emails, did:dsr.

Any guidance here?

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

1 participant