What degree should proof purposes be defined for specific application layer usages?

[kdenhartog]

It was brought up today in discussion around which proof purpose should be used for key agreement and signing of messages for DIDComm related keys. At first I thought, keyAgreement is fine for the agreement of a session key and the signing key could either be an authentication or assertionMethod key. However, using "authentication" means the key I allow to sign and assert messages for application concerns is also able to update the did document. In some cases, this is useful to reduce the complexity of managing many keys or in the case of did:key where it keeps the identifier short.

Similarly, assertionMethod is typically used for issuing credentials and as such the key used to issue credentials may not be best suited to be reused for signing an arbitrary message. This makes more sense when thinking about it in the sense of an organization where, a customer service representative is allowed to sign messages on behalf of the company, but should not be able to issue credentials on the companies behalf. Rather the key capable of handling issuance of credentials has greater access control considerations that have to come into consideration.

This got me thinking, should we be making statements about the considerations of proof purposes and to what degree they should be considered. Additionally, what statements do we need to add to the privacy considerations around this as well? For example, having a proof purpose of "CanOpen401MainStreetFrontDoor" as a proof purpose is a bit specific which leads to concerns around revealing PII about the subject.

What do others think we should be saying on this topic?

[dlongley]

However, using "authentication" means the key I allow to sign and assert messages for application concerns is also able to update the did document.

Aside: That depends on the DID method. Some DID methods like Veres One use object capabilities for authorization to do things like update a DID Document -- and therefore use the capabilityInvocation proof purpose.

But, even so, the thing that enables you to "update a DID document" (or for your update to be recognized) is still an "application". I think drawing a line here would be more harmful than helpful.

For example, having a proof purpose of "CanOpen401MainStreetFrontDoor" as a proof purpose is a bit specific which leads to concerns around revealing PII about the subject.

I agree that getting too specific would harm what proof purposes are designed to do. Proof purposes are supposed to enable a consuming application to know if the signed message they received was signed for the general purpose it is to be used for. It therefore provides an extra "post-signing" layer of security without revealing PII. It is designed to help ensure messages that were appropriately signed by an authorized party from being misused. It is not designed to stop unauthorized parties from signing certain messages.

That doesn't mean that proof purposes eliminate a need for people to know what they are signing or to set up appropriate rules around who can sign what using which keys. They are designed to help prevent something you signed from being used in a way you did not intend. Did you sign X because you wanted to make an assertion that could be shared somewhere ... or did you sign X because you wanted to authenticate yourself (and no one should be sharing that!)?

Ideally applications would eliminate all confusion regarding the signed payloads they accept, but that's not always the case. There are also cases where payloads can be interpreted in more than one way -- which can be abused by attackers. Proof purposes exist to help provide an extra layer of security by encoding general intent outside of the main payload. But, again, that doesn't remove a need for knowing what is signed or controls around signing authority. The goal here is to keep proof purposes in their own lane. One's intent with a signed message can be broken down into:

1. The general thing you're trying to do by signing, regardless of what the main payload is, e.g., are you trying to just say something (make an assertion), prove you are who you say you are (authenticate), take an action (capability invocation), allow others to take an action (capability delegation), etc. This is what proof purposes are for.

2. The specific thing you're signing; the exact details that you want people to know you signed off on.

Regarding encoding those specific details, they should be expressed using the main payload, e.g., using technologies like verifiable credentials and object capabilities. You can make very specific assertions in a standard way using the VC data model. Using object capabilities, what a signed capability enables you to do is specific to the capability and the target system where it will be invoked. You can have a capability that means "Open401MainStreetFrontDoor" and another one that means "SetMyKitchenOvenTo400DegreesFahrenheit" or "SignWithThisWebKMSKey". These capabilities don't need to be shared publicly.

You can also setup systems where a capability only enables you to sign specific types of messages using certain keys. These relationships may be internal to an organization, for example, and don't need to be expressed publicly in a DID Document. Using technologies like WebKMS, you do not need to give people direct access to key material to enable them to sign. You can also stand up applications that have stronger capabilities than the ones they hand out to their users. Users get capabilities that have been attenuated by more constraints on what may be signed. These are all approaches to "pre-signing" layers of security. They are for preventing people from signing things they shouldn't have been allowed to sign in the first place/only allowing them to sign those things they are specifically authorized to sign.

The point is that signing authority should be attenuated elsewhere, beyond the DID Document for very specific intent. What is important in these cases is constraining who can sign with what keys -- not whether an appropriately signed message being used for the right purpose. As always, security is an onion, and proof purposes are meant to provide an extra "post-signing" layer that sits beyond specific, private authority "pre-signing" decisions -- such that it aids against misuse, without revealing PII.

[kdenhartog]

Thanks for the detailed response @dlongley It's going to take me a bit to digest this and make sure I understand it over the next couple of days, but I think you're essentially saying "Don't do that application layer stuff at this layer, use OCAPs with VCs instead". Am I correct that's the general sentiment?

[dlongley]

I would say that the general sentiment is "proof purpose is for helping to prevent the misuse of properly signed messages, not managing who has the authority to use which keys" and "do that stuff at another layer". And -- those technologies I mentioned were just a couple of examples that could be used at that other layer.

[kdenhartog]

Ok, after taking a reread of both your comments I generally understand what you're talking about. I didn't see anything to this degree within the specification with the only discussion on verification methods in a note under publicKey property. I would think it would be useful to describe the purposes of verification methods more generally as a non-normative section at the bottom of the document to shed more light on their purpose and usage.

Given these have been around for awhile was there a reason for not clarifying them further or is this something that was just skipped over for some reason earlier and we should now add these details in?

[dlongley]

we should now add these details in?

Yes, we should add these details to the spec somewhere.

[kdenhartog]

Started a PR for this in #312