HTTPSig demo with Solid

Dear W3C Credentials Community,

The IETF’s “Signing HTTP Messages” spec [1] which Manu Sporny is working on is 
closing to the finishing line. I gave a demonstration of how this could be tied in
with Tim Berners-Lee’s Solid Project at the Solid CG meeting [2], in a video 
presentation which is online here on Twitter:


https://twitter.com/bblfish/status/1666547828506742788���
Today I presented the @ietf's upcoming HTTPSig protocol (@http_wg) at the @w3c Solid Community Group meeting. I illustrated it by running my #scala crawler on #BigData published as #LinkedData #EventStreams protected with #solidProject access control rules. This is about as…
 
The 🐠 BblFish
twitter.com

I quickly detail the working of the protocol, and have a few questions below:

# 1. Protocol description

The spec I am putting together in [3] works as follows. 
A client that receives a 401 with a WWW-Authenticate: HttpSig header such as

HTTP/1.1 401 Unauthorized
WWW-Authenticate: HttpSig realm="http://localhost:8080/ldes/bigClosedCF/stream"
Link: <http://localhost:8080/ldes/bigClosedCF/stream.acl>; rel=acl, <http://localhost:8080/ldes/bigClosedCF/>; rel=defaultAccessContainer
Server: reactive-solid/0.3 akka-http/10.2.10
Date: Wed, 14 Jun 2023 15:20:27 GMT
Content-Length: 0

knows that it can finds the access control rules by following the Link “acl” or “defaultAccessContainer" header.  If those rules allow it to access the resource with a given keyId then it can resent the 
request signed with a Authorization: HttpSig proof=sig1 

GET /ldes/bigClosedCF/stream HTTP/1.1
Host: localhost:8080
Accept: text/turtle, application/n-triples, application/rdf+xml, application/ld+json
Signature-Input: sig1=();created=1686756027;keyid="http://localhost:8080/rfcKey#"
Signature: sig1=:HBPnEttYKDHrvQOscnE08DPl60CI9vCVBWUTLoxZ1ADyuCCJb689N6prox9fX7/pqWELmi+k13Q4ELmWizIqQJphLNdtdpDsn2mpflehYMJPWC+dJuN3CBBAnjThDvZ8vjvynJU5my0zM6GAdpg3HPlInb6ocKTNBn4bJ4JYOZlVfMYO7RWIu1DJPevRWvRwivq1/qgKXwNbdObkTJxWNg6laxnPHAVdo5r5otqxdvtZHz0Sq5LyHU3PUeGm3FlQSjQcbm9M/aepT8zz9MhUwK9wKgzcmEbE7Imon7vHUg/ufgzZ+xp1s0YxuwkB/oc7j/3INg7P2y2yu3szOl86yQ==:
Authorization: HttpSig proof=sig1
Date: Wed, 14 Jun 2023 15:20:27 GMT
Connection: keep-alive
User-Agent: http4s-ember/1.0.0-M39
 
Note the keyid in the Signature-Input header. The HttpSig header allows us
to interpret the keyID as a URL that points to the keyID (on the same server here, so it could
be a relative url). 

The keyId information is  described using the security vocabulary. 
So keyd would return a turtle representation

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

<#> a security:JsonWebKey2020 ;
    security:controller </people/alice#i> ;
    security:publicKeyJwk """{
       "alg": "PS512",
       "note": "this is the key from https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures-13#page-82. Don't use for real world examples, as the private key is public knowledge",
       "use": "sig",
       "kty":"RSA",
       "e":"AQAB",
       "n":"r4tmm3r20Wd_PbqvP1s2-QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct-Lh1GH45x28Rw3Ry53mm-oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7OyrFAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL-Wokqltd11nqqzi-bJ9cvSKADYdUAAN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw9lq4aOT9v6d-nb4bnNkQVklLQ3fVAvJm-xdDOp9LCNCN48V2pnDOkFV6-U9nV5oyc6XI2w"
    }"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#JSON> .

And the JSON-LD representation is here:
https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/test/rfcKey.1.jsonld

The access control rules contain Authorization rules such as

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

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

https://github.com/co-operating-systems/Reactive-SoLiD/blob/master/test/.acl.1.ttl


# 2. Questions

One question would be if we are using the security vocabulary correctly. 
 (I need to update the spec to use that instead of cert:key )

I opened an issue "domain of publicKeyJWK should be rdf:JSON” as it seemed
the turtle should be using rdf:JSON as above
  https://github.com/w3c/vc-data-integrity/issues/73

It looks like controller is documented now and I think it fits, but it would be good to
have some feedback
https://w3c-ccg.github.io/security-vocab/#controller

There is also the question of whether sec:controller is the opposite of sec:publicKey
https://github.com/w3c/vc-data-integrity/issues/74

The document I am writing [3] is a bit less of a spec than an HOWTO guide 
and it gives a bigger overview to help explain why this is a good idea.

At prent I only have keyID authentication working. Later I would like to enhance
it with credentials.

Feedback welcome here, or in the solid authentication repository
https://github.com/solid/authentication-panel


Henry


[1] https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/
[2] https://github.com/solid/specification/blob/main/meetings/2023-06-07.md#httpsig-auth-demo
[3] see PR https://github.com/solid/authentication-panel/pull/235