You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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
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.
The text was updated successfully, but these errors were encountered: