Did-core: Need term for relying party

[jandrieu]

While working on the use cases document, @philarcher and I bumped into a problem with the diagram describing "DID Actions". We are working to update this diagram to incorporate innovations from new or emerging DID Methods that have features the original DID methods did not (such as teasing out creation from registration).

However, the one thing we have no consensus around is what do we call the party who, upon receiving a DID, does something with it, such as verifying a signature, creating a credential with that DID as the subject, verifying an authentication proof, etc.

Current language in the use case document calls this party the Relying Party. In the VC conversation, that term was eschewed in favor of "Verifier". In some cases, that party could be called a "Resolver" in the sense that they are using the did to look up the DID Document, but that term is firmly established as the SOFTWARE that does resolution rather than the party who needs to resolve a DID to do something interesting.

Suggestions for alternatives welcome.

bikeshed on

[peacekeeper]

what do we call the party who, upon receiving a DID, does something with it

I'm not sure if any new, universal term is needed for that, doesn't the term for that party depend on WHAT the party does? If it verifies a credential, it's a Verifier. Etc.

In some cases, that party could be called a "Resolver" in the sense that they are using the did to look up the DID Document, but that term is firmly established as the SOFTWARE that does resolution

In the DID Resolution spec, that's called a _client_. We could change that to _"DID client"_ or _"DID resolver client"_?

Also note that there may be use cases where DIDs are used in ways that don't require resolution. Hmm _"DID user"_?

[agropper]

+1 Markus. If I understand him, I agree that Relying Party is confusing.

In my world, a Requesting Party uses a Client to access a protected Resource under the control of a Subject.

[dmitrizagidulin]

@agropper I agree, Requesting Party is an excellent term that might fit here.

[OR13]

Why are we not using the term "Relying Party" if that term is already commonly used... adding new terms that are close to but not equivalent to existing terms seems dangerous.

[msporny]

+1 to Requesting Party... given that Relying Party is already widely known in the industry :(

EDIT: I now think I'm a +0 to Requesting party, see https://github.com/w3c/did-core/issues/248#issuecomment-641505821

[talltree]

It's worth mentioning that, in a verifiable credential context, the term "verifier" is now in wide usage. I end out explaining that "verifier" is used in place of "relying party" in most discussions of decentralized identity. I'm not necessarily suggesting that "verifier" is the best term in a DID context, but I think it should at least be mentioned that this term is defined and used in conjunction with VCs, and many VCs will use DIDs.

[msporny]

Unfortunately, "Relying Party" definition is OpenID specific and assumes that the subject is asserting claims about itself, or is using an identity provider to do the same. The definitions don't line up.

https://en.wikipedia.org/wiki/Relying_party
https://en.wikipedia.org/wiki/OpenID

[OR13]

+1 for "Requesting Party" with a callout to OpenID and the potential confusion.

[msporny]

It's worth mentioning that, in a verifiable credential context, the term "verifier" is now in wide usage.

For some reason, I missed @talltree's very solid suggestion, possibly because I thought @jandrieu disagreed that "verifier" was the correct term.

Why can't we just re-use "Verifier"? What is different here. Can you provide a concise definition, @jandrieu -- what goes on the right hand side of this word in a terminology section?

[brentzundel]

I prefer "Requesting Party" because the VC "Issuer", "Holder", and
"Verifier" could each be a "Requesting Party" as far as DIDs are concerned.

On Tue, Jun 9, 2020 at 12:54 PM Manu Sporny [e-mail]
wrote:

It's worth mentioning that, in a verifiable credential context, the term
"verifier" is now in wide usage.

For some reason, I missed @talltree https://github.com/talltree's very
solid suggestion, possibly because I thought @jandrieu
https://github.com/jandrieu disagreed that "verifier" was the correct
term.

Why can't we just re-use "Verifier"? What is different here. Can you
provide a concise definition, @jandrieu https://github.com/jandrieu --
what goes on the right hand side of this word in a terminology section?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/248#issuecomment-641505821, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPFKP4YUD2FC64OGTBCJWDRV2ANFANCNFSM4LZRLL4A
.

[jandrieu]

Not all DID uses lead to "verifying" anything. I can give you a DID for how to contact me, you put that in your contact list, and later you look up a service endpoint and contact me. No verification at all.

Unfortunately, in that case, "requesting party" is not necessarily right either, because I gave you the DID on my Business Card. You didn't request it.

Also, to Brent's point, we have a different set of roles than VCs. Reusing them creates name collisions, which won't help people understand.

It's not clear to me what to call someone who gets a did from somewhere then does something with it. Should the term be different based on what you do with it?

[msporny]

It's not clear to me what to call someone who gets a did from somewhere then does something with it. Should the term be different based on what you do with it?

Yes, or to put it another way -- the role you play in a system is dependent on what your purpose is in that system.

Still waiting on a definition for the role we're trying to identify in the system. From what you said above, it's something like:

??????? - An entity that receives a DID.

Does that definition cover what you want to name, @jandrieu?

[jandrieu]

I would say "use" a DID. But that way lies madness.

[OR13]

Let "DID User" be a person who utilizes a decentralized identifier for any purpose.
Let "Issuer" be a "DID User" who issues credentials.
Let "Subject" be a "DID User" who identifies themself with a DID.
Let "Prover" be a "DID User" who presents credentials to a "Verifier".
Let "Verifier" be a "DID User" who verifies presentations.
Let "Lender" be a "DID User" who transfers currency to a "Lendee" with expectation of repayment.
Let "Lendee" be a "DID User" who receives currency from a "Lender".
Let "Doctor" be a "DID User" who writes prescriptions for "Patients".
Let "Pharmacist" be a "DID User" who fills prescriptions from "Doctors"
...

[brentzundel]

"user" does have a nice ring to it.

On Tue, Jun 9, 2020, 20:05 Joe Andrieu [e-mail] wrote:

I would say "use" a DID. But that way lies madness.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/248#issuecomment-641675372, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPFKP4DAKXW5CXYLWK6HXDRV3S5LANCNFSM4LZRLL4A
.

[ChristopherA]

I think DID Abuser has a good ring to it too.

:-)

[agropper]

+1 to DID User. I would reserve Requesting Party to cases where the (DID)
user is providing their own credentials and intended uses to a DID Service
Endpoint in order to access a protected resource.

On Tue, Jun 9, 2020 at 11:17 PM Christopher Allen [e-mail]
wrote:

I think DID Abuser has a good ring to it too.

:-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/did-core/issues/248#issuecomment-641695150, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABB4YNCZ43QYPUJ7C2RL23RV33N7ANCNFSM4LZRLL4A
.

[msporny]

Warning: strong opinion follows :)

Use Cases that utilize the word "user" to define a role in the system are not helpful for a variety of reasons:

• The word user is so generic that it gives the reader very little insight into the role. It's the word you use when you don't know any better, when you need a catch-all term, or haven't clearly defined the purpose of the role in the system.
• There are only two professions that use the word "user" when describing the people that use their systems -- computer scientists and drug dealers. Don Norman wrote some great stuff on the dangers of calling people users.

The use of the word "user" is a lazy catch-all at best, and at worst, dehumanizes the person utilizing the system.

-1 to DID User :(

[philarcher]

From what I can see, the options are:

• Relying party (current phrase, @OR13 supports, several against)
• (DID) client (used in DID Resolution, @peacekeeper supports)
• Requesting Party (@agropper , @dmitrizagidulin , @msporny, @brentzundel, @OR13 latterly)
• Verifier (@talltree, @msporny latterly)
• DID user (@agropper latterly, @msporny strongly opposes)

Some people have changed their minds over time (which is allowed!)

But from the above, if there's anything like a consensus here, it's around Requesting Party. Are there any strong -1s for 'Requesting Party' ?

[Identitywoman]

I like Requesting Party as an alternative because it avoids the confusion with Relying Party that is an OpenID and they in tern drew it from enterprise identity and access management federation.

[jandrieu]

Based on the closure on F2F call: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-06-30-did, we can close this out once we get a PR in.

[philarcher]

PR #350 swaps the 3 instances of the term relying party for requesting party, in line with the WG resolution of 30 June and with the equivalent action taken in the UCR. This issue can be closed if and when that PR is merged.