HttpSig #125
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -73,7 +73,7 @@ It may also be possible to send the ACL rules directly in the body (Todo: resear | |||||
|
|
||||||
| ### The KeyId URL | ||||||
|
|
||||||
| In order for it to be clear that the `keyId` is to be interpreted as a URL, the `keyId` field MUST enclose the URL with `'<'` and `'>'` characters. | ||||||
| To take an example from [§A.3.2.1](https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-01#appendix-A.3.2) of `Http-Sig` this would allow the following use of relative URLs referring to a resource on the requested server | ||||||
|
|
||||||
| ```HTTP | ||||||
|
|
@@ -91,17 +91,14 @@ located elsewhere on the web, such as the requestor's [Freedom Box](https://free | |||||
|
|
||||||
| ```HTTP | ||||||
| Signature-Input: sig1=(); keyId="<https://alice.freedombox/keys/test-key-a>"; created=1402170695 | ||||||
| Signature: sig1=:cxieW5ZKV9R9A70+Ua1A/1FCvVayuE6Z77wDGNVFSiluSz...==: | ||||||
| ``` | ||||||
|
|
||||||
| It could also allow key based did URLs as described in [issue 217 of the Solid Spec](https://github.com/solid/specification/issues/217#issuecomment-777509084). | ||||||
|
|
||||||
| The advantage of a URL is that it allows the client to use HTTP Methods such as `POST` or `PUT` to create keys, as well as `PUT`, `PATCH` and `DELETE` to edit them, solving the problem of key revocation. | ||||||
|
|
||||||
| We also reserve the use of keyIds enclosed with `'>'` and `'<'` characters for | ||||||
| possible extensions of HTTP such as the [Peer-to-Peer Extension to HTTP/2 draft](https://tools.ietf.org/html/draft-benfield-http2-p2p-02) as discussed on the [ietf-http-wg mailing list](https://lists.w3.org/Archives/Public/ietf-http-wg/2021JanMar/0049.html). | ||||||
| This would allow the client to let the server know that it can request the key by making an HTTP `GET` request on the given relative URL, reducing to a minimum the reliance on the network. | ||||||
| With such a protocol available, the request could be signed as follows | ||||||
|
|
@@ -226,8 +223,8 @@ App Server Doc Cred | |||||
| | | | | ||||||
| | verify sig | | | ||||||
| | | | | ||||||
| | |-(6) GET credential----------------->| | ||||||
| | |<-----------------(7) credential doc-| | ||||||
| | | | ||||||
| | WAC verification | | ||||||
| | | | ||||||
|
|
@@ -237,10 +234,12 @@ App Server Doc Cred | |||||
| Steps (4) and (5), where the server retrives a (cached)copy of the key, are as before. | ||||||
|
|
||||||
| Steps (6) can be run in parallel with (4) to fetch the Credential document. | ||||||
| This also can be cached. | ||||||
| If the `Credential` header URL | ||||||
| * is enclosed in '<' and '>' then | ||||||
| * if it is relative it can be fetched on the same server | ||||||
| * if is is an absolute URL it can be fetched by opening a new connection | ||||||
| * is enclosed in `>` and `<` and P2P HTTP extension is enabled, the server can request the credential from the client directly using the same connection opened in (3). | ||||||
|
There was a problem hiding this comment. As above, I think this probably should be
Suggested change
There was a problem hiding this comment. Same point as above. Perhaps this is such an unusual idea that it requires more elaboration, perhaps even a picture or something. There was a problem hiding this comment. I think it requires a lexical/literal example, at minimum. If there are other wrapping characters -- whether brackets, braces, parentheses, quotation marks, or otherwise -- which may be used in a more typical manner (the only thing I can quickly think of that uses There was a problem hiding this comment. The way I see it is in terms of indexicals eg: I and you. In an HTTP connection of a client There was a problem hiding this comment. Making such distinction doesn't seem to require any specific wrapping characters. It requires knowing who's "speaking", and to whom -- as the entity to which the possessive "my" or "your" refers changes in meaning with the speaker and the audience. In HTTP, we can speak of the Client and the Server, and describe what action each might be taking (requesting, responding, etc.). In other spheres, we have conventions like Requesting Party, Relying Party, Responding Party, etc., to serve the same purpose. Sometimes, it's very hard to describe an interaction with generalities, but trivial to describe it through a concretized example. I think this might be one of those situations, at least at this point in the ecosystem's development. There was a problem hiding this comment.
Let us say we start with a connection from Phone to Pod . So we want to allow the following two possibilities to exist:
The relative path There was a problem hiding this comment. I wrote more about what P2P opens up to the web here w3c/architecture#14 |
||||||
|
|
||||||
| ### Linking a WebKey to a WebID | ||||||
|
|
||||||
|
|
@@ -316,4 +315,5 @@ This would allow resources to be protected with a rule such as | |||||
| A client after receiving the response (2) in the above sequence diagram can search for the relevant [Verifiable Credential](https://www.w3.org/TR/vc-data-model/) in its credential store (containing perhaps a Drivers Licence, Birth certificate or MI6 007 licence to kill), order these in a privacy lattice, and choose the one the more appropriate for the task at hand. | ||||||
| The URL for that Credential can then be sent in the header (3). | ||||||
| The verification process then needs to verify that the signature is correct, and that the credential identifies the user with the same key, and is signed by a legitimate Certificate Authority. | ||||||
| How to determine which Certificate Authority are legitimate for which claims, is outside the scope of this specification. | ||||||
| This is known in the Self-Sovereign Identity space as a Governance Framework, and in the end will lead to a [Web of Nations](https://co-operating.systems/2020/06/01/WoN.pdf). | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This suggests
>{keyId}<which I think is not what is intended."Enclosed with" usually enumerates first the prepend and second the append -- so if the intent is (as I believe)
<{keyId}>, this should readThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
>{keyId}<is exactly what was intended! :-)The idea is that we want a way to say: this is the relative URL for the key, but it is not to be found out there on the internet, but by asking the client for it.
How does one ask the client for it? By using the P2P extension of HTTP/2 referred to, which allows the server to take on the role of a client on the same connection.
Do you think
>{keyId}<would be clearer?