Should we rename "verification relationships" to "authorization relationships"?

[kdenhartog]

We may want to call "verification relationships" "authorization relationships" instead. It may be a better term.

Originally posted by @dlongley in https://github.com/w3c/did-core/pull/312

My initial thoughts on this are that I think the term more accurately describes the relationship between the did subject and the verification method (don't think we'd rename these to authorization method FWIW). However, I'm wondering if the use of authorization (since it's an overloaded term) would turn into a landmine for us.

Where do others fall on this issue?

bikeshed on

[OR13]

bro... please stop renaming things.

[dlongley]

If we do change this terminology, it wouldn't affect implementations in this particular case.

[csuwildcat]

Given the bikeshed 🚲 door 🚪 now appears to be wide open, may I take this opportunity to suggest 'indulged acquaintanceships'?!? 👌 bellissimo finger kiss

[peacekeeper]

I'm not sure why "authorization" would make more sense than "verification". I thought public keys, ethereumAddress, hashed passwords, biometric things, multi-sig crypto are all ways to prove control of a DID ("verify" that a proof was produced by the DID controller). Authorization is separate from that, no?

[csuwildcat]

On a serious note: in light of Markus' thoughtful enumeration of what the term covers, when paired with the fact we have the concept of 'control' and proving control, wouldn't the logical choice (if one were to modify this term) be to call it 'control relationships'?

[dlongley]

@peacekeeper,

I'm not sure why "authorization" would make more sense than "verification". I thought public keys, ethereumAddress, hashed passwords, biometric things, multi-sig crypto are all ways to prove control of a DID ("verify" that a proof was produced by the DID controller). Authorization is separate from that, no?

The discussion here is not about renaming verification methods -- which are what you describe above. This is about renaming the category of relationships (aka properties) that express that particular verification methods are authorized to verify proofs made by or on behalf of the DID subject for a specific purpose. In other words, what is the category name for things such as "assertionMethod", "authentication", "capabilityInvocation", "capabilityDelegation". This category name is currently "verification relationships". The proposal here would be to rename those to "authorization relationships" (or some other bikeshedded name).

The fact that we're just considering renaming the category that these fall under is also why I mentioned that this would not affect implementations -- it would only be to try and help better explain what these relationships/properties are about.

[dlongley]

A call would be helpful to discuss this issue.

[dlongley]

Still waiting on some space during a special call where this could be discussed.

[kdenhartog]

Originally, I thought it would be beneficial to change the name on this because I expected it to be a conceptual name only for use in the spec, but I've seen variables that have started to use this where changing this name would cause breaking changes to code now. It's my preference at this time that we stick with what we have and live with it going forward. @OR13 and @csuwildcat would likely take a similar preference, but I'll let them speak for themselves.

[csuwildcat]

@dlongley folks in some Working Groups and projects are crafting their API, library, and inner-implementation strings to match DID Core's current property names under the belief that aligning every string they have in their APIs/libs is the right thing to do. I cannot say I agree with this approach/belief, but given I am being exposed to the issues that DID Core string changes would cause, it puts me in a position where the only way not to get wrecked is to oppose literally every string change that is attempted in DID Core. If you don't think folks proceeding under this notion of immutable adherence is advisable, please do say so (I tried, but will probably get overruled).

[dlongley]

@csuwildcat,

I cannot say I agree with this approach/belief, but given I am being exposed to the issues that DID Core string changes would cause, it puts me in a position where the only way not to get wrecked is to oppose literally every string change that is attempted in DID Core. If you don't think folks proceeding under this notion of immutable adherence is advisable, please do say so (I tried, but will probably get overruled).

Yeah, I don't think it's advisable but it's also not unexpected. People are expecting some kind of stability because they are moving forward with implementations -- even if they shouldn't be. We're not even to CR yet, but we are getting very close. Once we're in CR that's a much better time to expect things not to change as that's when the call for implementations occurs and when the process gets heavy for the WG if we need to make any changes that will affect implementations.

Regardless, "verification relationship" is not a property, so changing its name doesn't affect implementations. It would be a purely non-normative/informative change. I know some people have sometimes confused "verification relationship" with "verification method" or "verificationMethod" which is a property, but that's part of the reason for considering a different name for "verification relationship". Personally, I don't care all that much if we keep the current name or change it provided that we're clear in its description.

I'm happy for us to close this if people are disinterested in pursuing another name. We can always make this change later if this comes up again because it would be non-normative.

[csuwildcat]

@dlongley I completely understand your response, and believe it's the normal, rational, practical, and obviously correct answer to the issue. Unfortunately, I'm dealing with a situation where other WG members are literally arguing that every string in every other API/spec they create must use some string in the DID Core spec, even if it's entirety non-normative, and that we should lock ourselves to them now, with the 'solution' to the horrible outcome of drift from strange terms that change under us being formal objections to literally every attempt to change any terms in the spec from here on through eternity. To be clear: I disagree with these folks vehemently, but it may be a case where I simply get overruled and am left to deal with basically 0 options but to walk the ill-advised path of constant objection to all string changes. I'm sorry in advance if this happens, seriously. It's 3:01am where I'm at, so I'm going to go back to losing sleep over this - literally.

[OR13]

@csuwildcat on the thread you linked, I am not arguing for all strings to match did core terms.... and enum is a type which maps to strings.... in this case, I am suggesting the string values, map to the normative properties of a did subject, in order to clearly communicate which verification relationship key material will end up in.

Here is the current code that does this:

https://github.com/decentralized-identity/sidetree/blob/master/lib/core/versions/latest/PublicKeyPurpose.ts

/**
 * Sidetree public key purpose.
 */
enum PublicKeyPurpose {
  Auth = 'auth',
  General = 'general'
}

export default PublicKeyPurpose;

My proposal as nothing to do with the symbol PublicKeyPurpose.... its is about the string values of the enum...

I think it's confusing for developers to be asked to manage 2 sets of strings.... for example,

see: https://w3c.github.io/did-core/#core-properties

auth -> authentication general -> verificationMethod | publicKey

and your code is missing all the relationships needed for encrypted data vaults and verifiable credentials, which are:

keyAgreement assertionMethod capabilityInvocation

etc....

These strings are normatively defined in did core, yet sidetree is choosing new string names for them, which is confusing for developers.

[mprorock]

to echo @OR13 keeping consistent naming with did core is much better for us, especially as we are onboarding new developers. consistency and interoperability is optimal in almost all cases. there is no need to choose new string names here, especially when there is a normative precedent.

[csuwildcat]

@mprorock there's a high likelihood that we're going to immutably lock-in some strings (many rather obtusely named) that only make sense if you read DID Core as of whatever day in the endlessly churning sea of DID Core term changes you decided to bind yourself to them, which later will change, leaving us with a set of strings in our code that look like random nonsense. The degree to which this likelihood is being blithely ignored is deeply concerning.

[OR13]

@csuwildcat instead of betting on things changing, why not work to stabilize them, and say you will object to changes to any of the current properties in https://w3c.github.io/did-core/#core-properties

that would be significantly more helpful than fear mongering about did core changing properties.

[csuwildcat]

Universal objection to string changes before CR ends and the review is triaged for changes isn't proper, normal, or helpful, it's being an obstinate punk for reasons one shouldn't. CR and this process is supposed to uncover issues, and those issues/comments may justly result in modifications to the spec - taking a 'strings need to be etched in stone now' stance simply isn't normal or rational.

[OR13]

@csuwildcat so you are saying you both fear changes and want them to happen?

regarding properties of the did subject like service perhaps we can remove it after all?

or are you saying we need to keep it but you want its name to change?

I recall you already threatened to object if it was removed.

[dlongley]

@OR13,

My read of what @csuwildcat is referring to is a blanket policy to object over any change as opposed to reasoning through each potential change individually.

There's a middle ground here where the group should be aware that people are proceeding with implementations and we should be careful not to change anything that we really don't need to. But the people doing the implementations should also be aware that there could be changes that the group decides really do need to happen. And the latter is more likely before CR, becomes significantly less likely during CR (to the point that many people may take a blanket objection approach, but changes are still possible if absolutely necessary). Then once we're through CR it's going to be nigh impossible to change anything in this version of the spec.

I would guess that you're actually probably both supportive of this position and just miscommunicating a bit.

[msporny]

Seems like no one wants to change "verification relationships" to "authorization relationships" at this point. I'm marking this issue as pending close. This will be closed in 7 days unless there are objections.

[brentzundel]

No comments since marked pending close, closing