- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 14 Jun 2023 18:43:20 +0200
- To: W3C Credentials Community Group <public-credentials@w3.org>
- Message-Id: <11B4A058-69A9-46ED-A152-E01B83F420F0@bblfish.net>
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
Attachments
- text/html attachment: stored
- image/jpeg attachment: M3fN2SQUcBQyhX6e.jpg
Received on Wednesday, 14 June 2023 16:43:41 UTC