relating an agent to their key?

[bblfish]

In solid Web Access Control we need ways to describe agents via their key. Currently the access control rule demo on Reactive Solid test/.acl uses a blank node and the security:controller relation.

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

<#R3> a wac:Authorization;
   wac:agent _:a ;
   wac:mode wac:Read, wac:Write;
   wac:default </> .

</rfcKey#> security:controller _:a .

I am using it here as if it were the inverse of cert:key.
Is that correct?

Do you have anything like cert:key ? It would be better to write

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

<#R3> a wac:Authorization;
   wac:agent [ cert:key </rfcKey#> ] ;
   wac:mode wac:Read, wac:Write;
   wac:default </> .

Actually much better would be to link to a WebID

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

<#R3> a wac:Authorization;
   wac:agent </Mary#>;
   wac:mode wac:Read, wac:Write;
   wac:default </> .

and then have the WebID document at </Mary> describe information allowing any number of authentication mechanisms.

<#> a foaf:Person;
     cert:key <did:key:...>;
     foaf:openid </index.html>;
     foaf:mbox <Mary@littlelamb.com> .

As a side question I think I remember hearing that did's refer to the agents? Is that true of did:key? in which case would it not be more correct to write

<#> a foaf:Person;
   foaf:name "Mary";
   owl:sameAs <did:key:...> .

[msporny]

I am using it here as if it were the inverse of cert:key. Is that correct?

Yes, that's correct, AFAICT.

Do you have anything like cert:key?

Yes, we call them "verification methods", of which a public key (subclass) is one type of verification method (superclass). Other types of verification methods could be a TOTP identifier (that is, an oracle where you know the answer to it's questions), a turing test, a security token service, or a biometric template (but we feel uneasy about suggesting that for a variety of reasons).

An explanation of verification methods can be found here:

https://www.w3.org/TR/vc-data-integrity/#verification-methods

Verification methods are expressed in controller documents:

https://www.w3.org/TR/vc-data-integrity/#controller-documents

Controller documents are, unsurprisingly, analogous to WebID documents (as I'm sure you realize where all this stuff originated, @bblfish -- those many, many years ago) :)

A controller document expresses a subject (such as Mary) and states that she has a variety of verification methods associated with her, through "verification relationships" (which are just RDF predicates). So, this is the pattern:

<controller> <verification relationship> <verification method>

or more specifically:

<#mary> <sec:authentication> <#public-key-1>

Which roughly translates to "#mary's authentication method is #public-key-1"

So, that's how we relate "agents" to their "keys" both in the Decentralized Identifiers specification and in the Data Integrity specification.

A "controller document" is effectively a "WebID document".
A "public key" is a type of "verification method".
A "verification relationship" is how you relate a "controller document subject" to a "verification method".

Does that make logical sense, @bblfish?

[msporny]

This issue has been answered, waited 3 weeks for issue submitter to respond. Marking as pending close. This issue will be closed after a 7 day wait period.