security vocabulary definitions

It is a bit difficult to work out what the definitions of some of the concepts we are using are and where they are located, which ones are stable and not. So as we are making decisions on how to use these we need to track these carefully.

security:controller

In a discussion on JWK in the Authorization Panel I was looking for the definition security:controller and opened issue 114 on w3c-ccg-vocab as a result. @acoburn pointed out that the did specification gives the definition of did:controller:"

A DID controller is an entity that is authorized to make changes to a DID document. The process of authorizing a DID controller is defined by the DID method.

The Did Namespace document identifies it with https://w3id.org/security#controller. So the above DID definition would be the definition of security:controller at least when the subject of the relation is a did document. The example given in the next section shows that controller need not be limited to did documents.

did:publicKeyJwk

There is also a definition for publicKeyJwk in the did spec.

The publicKeyJwk property is OPTIONAL. If present, the value MUST be a map representing a JSON Web Key that conforms to [RFC7517]. The map MUST NOT contain "d", or any other members of the private information class as described in Registration Template. It is RECOMMENDED that verification methods that use JWKs [RFC7517] to represent their public keys use the value of kid as their fragment identifier. It is RECOMMENDED that JWK kid values are set to the public key fingerprint [RFC7638]. See the first key in Example 13 for an example of a public key with a compound key identifier.

But that does not help us with what the domain of it is that much...

Note that one has to go to https://w3c-ccg.github.io/lds-jws2020/contexts/v1/ to find the definition, as it is not available in the basic did namespace document, and there one finds that it is security:publicKeyJwk.

It is also defined in the security vocabulary security:publicKeyJwk and that gives some useful information:

See IANA JOSE. See also RFC 7517.

    <dl>
      <dt>Status</dt>
      <dd property="vs:term_status">stable</dd>
      <dt>Domain</dt>
      <dd>Key</dd>
      <dt>Range</dt>
      <dd>xsd:string</dd>
    </dl>

{
  "id": "did:example:123#_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A",
  "type": "JsonWebKey2020",
  "controller": "did:example:123",
  "publicKeyJwk": {
    "crv": "Ed25519",
    "x": "VCpo2LMLhn6iWku8MKvSLg2ZAoC-nlOyPVQaO3FxVeQ",
    "kty": "OKP",
    "kid": "_Qq0UL2Fq651Q0Fjd6TvnYE-faHiOpRlPVQcY_-tA4A"
  }
}

This is what I was looking for, as the domain is here defined to be Key though that is only done in english without an accompanying RDF domain restriction (as far as I can see). That actually confirms my reading of keyId referring to a key. It is nice because this example also comes with a publicKeyJwk example.

did:subject

That also gives the definition of did:subject.

The DID for a particular DID subject is expressed using the id property in the DID document.

The entity identified by a DID and described by a DID document. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc.

The namespace document just maps that to @id.

So that allows the did:subject to be pretty much anything and it does not affect our interepretation of what the keyId is.

Provisional conclusion

The security:controller links the key to the agent that controls the publication of that key. In our case that is the Solid Resource in which the key is published.

We now have two controllers:

the controller of the document determined by the Access Control relation for that document
the security:controller relation

So that does raise the question whether the security:controller should not select one of the controllers of the associated ACR?

Are we sure we can have the security:controller range refer to the WebID of the person owning the key? Does that follow from these definitions?

solid / authentication-panel