JWK in Access Control

[bblfish]

In the AuthN issue 156: Ontology for KeyID document we came to the conclusion to use the JWK security vocabulary. Alice could then publish her public-key in the document https://alice.me/keys

@prefix security <https://w3id.org/security#> .

<#k> 
     security:controller <https://alice.me/profile/card#me> ;
     security:publicKeyJwk """{
                "alg":"PS512",
                "e":"AQAB",
                "kid":"2011-04-29",
                "kty":"RSA",
                "n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78L..."
      }"""^^rdfs:JSON .

The security:publicKeyJwk relates the KeyId <#k> from Signing HTTP Messages v05, to the JWK signature key and algorithm. The security:controller relates the KeyId to what I believe is the WebID. The json "controller" attribute is given a namespace in the security context vocabulary v2 and especially in the security vocabulary v3. But it is not defined in the security vocab spec - so I opened issue 114 there.

Having added this to the AuthN side, we need to look at using it in AuthZ. There are two ways to do this using the above vocabulary elements and the work on Web Access Control ontology.

AC Rule points to WebID

@prefix  acl:  <http://www.w3.org/ns/auth/acl#>  .

<#autz1> a acl:Authorization;
    acl:agent     <https://alice.me/profile/card#me>; 
    acl:accessTo  <https://alice.me/docs/file1>;
    acl:mode   acl:Control.

The Guard having verified the keyId would need a link fro Alice's WebID Profile to the KeyID Document. It would need to find the following statement in the WebID Profile

</keys#k> security:controller <#me> .

AC Rule indirectly identifying the user by the key

The AC Rule could also indirectly identify the agent via the key as in the following N3,

<#autz2> a acl:Authorization;
    acl:agent    [  is security:controller of <https://alice.me/keys#k> ];
    acl:accessTo  <https://alice.me/docs/file1>;
    acl:mode  acl:Read.

Note: the is ... of construction is N3 syntactic sugar to write an inverse relation.

This would not require one to go through a WebID.
It means though that we would be conceiving of the security:controller relation as a functional property: every key has one controller agent. There is no textual description on the security vocabulary of what the range of the controller relation is. As @OR13 mentioned in issue 156 above work on the security ontology has gotten stuck in mega thread. So perhaps we should look to some clarification on the meaning of it. In a way the security:controller relation is acting similarly to the cert:key relation from the cert ontology which is an inverse functional property that relates an agent to a cryptographic key (but without specifying the hashing algorithm).

Other considerations?

[TallTed]

sighs Stupid half-done github discussions UI doesn't have a mouseover explanation of the little up-arrow beside the title, which suggests there's something preceding this page ... but no, it's some kind of rating or voting system, which only allows an up-vote and doesn't let you UNDO a click (so there's at least one accidental up-vote from me), nor down-vote as should always be possible where there are up-votes.

And this is a (meta-)comment, not an answer, but there's no way to add a comment on the question, because github hasn't learned from other discussion and/or q&a sites.

I do not think semi-threaded "discussions" add enough benefit to justify moving from "issues".

[bblfish]

It is worth discussing that. Perhaps open an issue for this? We can see what other pros and cons there are to this discussion forum. I see there is a "beta give feedback" button on the right.

[acoburn]

For the controller property, you may find the definition in the DID specification useful

[bblfish]

Ah! good find. (I left a comment on the issue as that set of links is difficult to find)

So it looks like we should perhaps be using using did:subject

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.

Ah! but that is subject of the security:publicKeyJwk relation I believe. So it looks like it is equivalent to our WebID in a way?
I was thinking there would be a way to name the intermediate key material. But well here we have a key that is a literal, whereas in the cert ontology it was a node for a PublicKey.

[bblfish]

This is related to the question that @elf-pavlik asked on Gitter May 03 2021 21:21 ECT:

in solid-oidc the application gets verified user's WebID from the id_token https://solid.github.io/authentication-panel/solid-oidc-primer/#authorization-code-pkce-flow-step-21
in your Http Signatures based approach, how does the application get a verified user's WebID ?

So it looks like the keyid is an equivalent to a WebID. And that is what is passed in the HTTP Sig headers.

Whether we would need something more fine grained like a real Id for the key material, as in the cert ontology, is an open question.

[bblfish]

I had a much closer look now at the definitions, and I am back to the conception I had before, that the keyId refers to a key. I went through the definitions in solid/authentication-panel#179