Create header-HTTP-Header content

[gboege]

Remarks:

• change to "header" from "dth-header" ... this is due to alignment with the standard
• value of header must be a quoted string with all doublequote escaped
• no spaces in the quoted string

Message-Type for Requests is "QueryMessage" Message-Type for Responses is "ResultMessage"

[gboege]

a) Just adding the IDS header part from the multipart-messages as an additional header to the original HTTP Call (the content of the header-Header is matching the example from 4.4.2 2. QueryMessage):

The additional header-HTTP-Header follows the extension-header mechanism that allows additional entity-header fields to be defined without changing the protocol (https://www.rfc-editor.org/rfc/pdfrfc/rfc2616.txt.pdf - section 7.1). The value of the header-HTTP-Header must be formatted as a quoted-string containing qdtext escaping the forbidden " VCHAR to a quoted-pair \" (https://tools.ietf.org/html/rfc7230 - section 3.2.6).

[gboege]

The creation of the content of the header-Header is pre-created in the ballerina script. It contains all steps to obtain the securityToken (first create own JWT and then obtain DAT from DAPS). Explanations to the other fields are following soon. There are some unique IDs for reference, some timestamps and some data to be parameterized during creation (modelVersion with Updates ca. each year and IssuerConnector individual for each connector).

[chicco785]

@gboege having a header containing JSON is not really optimal and raise several encoding issues. What's the rational?

[c0c0n3]

See #13

[gboege]

@chicco785 The Data Transfer Header by definition MUST follow the IDSA Datamodel and must be serialized in JSON-LD...

I appreciate the from Andrea to Base64-encode the complete JSON string. This should solve the problem of escaping, right? We can change the definitions in IDSA if we agree upon, currently it is only us to push the header solution.

[c0c0n3]

@gboege thanks for clarifying :-)

Base64-encode the complete JSON string

This would make our life much easier. In fact, handling HTTP header values correctly has historically been a source of headaches for many before us. In particular, even Go built-in libs seem to have trouble with quoted values, e.g. something like header: "{\"url\": \"http:\/\/golang\"}"---see comments to #13. Also, if there's any escaping in the original JSON doc, we'd have to handle that too---which I'm not doing at the moment, just pushed my code to the dev branch, have a look at orionadapter/sec/tokenrep.go.

So this looks like a slippery road downhill. Any chance we can push for the IDS header value to be Base 64 encoded e.g. a header value of

{
    "@type": "ids:QueryMessage",
    "id": "http://industrialdataspace.org/queryMessage/1a421b8c-3407-44a8-aeb9-253f145c869a",
    "issued": "2019-10-25T15:35:34.589Z",
    "modelVersion": "2.1.0",
    "issuerConnector": "https://companyA.com/connector/59a68243-dd96-4c8d-88a9-0f0e03e13b1b",
    "securityToken": {
            "@type": "ids:DynamicAttributeToken",
            "tokenFormat": "https://w3id.org/idsa/code/tokenformat/JWT",
            "tokenValue": "my.fat.jws"
    }
}

would be sent over the wire as

header: ewoJIkB0eXBlIjogImlkczpRdWVyeU1lc3NhZ2UiLAoJImlkIjogImh0dHA6Ly9pbmR1c3RyaWFsZGF0YXNwYWNlLm9yZy9xdWVyeU1lc3NhZ2UvMWE0MjFiOGMtMzQwNy00NGE4LWFlYjktMjUzZjE0NWM4NjlhIiwKCSJpc3N1ZWQiOiAiMjAxOS0xMC0yNVQxNTozNTozNC41ODlaIiwKCSJtb2RlbFZlcnNpb24iOiAiMi4xLjAiLAoJImlzc3VlckNvbm5lY3RvciI6ICJodHRwczovL2NvbXBhbnlBLmNvbS9jb25uZWN0b3IvNTlhNjgyNDMtZGQ5Ni00YzhkLTg4YTktMGYwZTAzZTEzYjFiIiwKCSJzZWN1cml0eVRva2VuIjogewoJCSJAdHlwZSI6ICJpZHM6RHluYW1pY0F0dHJpYnV0ZVRva2VuIiwKCQkidG9rZW5Gb3JtYXQiOiAiaHR0cHM6Ly93M2lkLm9yZy9pZHNhL2NvZGUvdG9rZW5mb3JtYXQvSldUIiwKCQkidG9rZW5WYWx1ZSI6ICJteS5mYXQuandzIgoJfQp9

This should solve the problem of escaping, right?

Yes as well as double-escaping nightmares if there's any escaping in the original JSON doc.

[gboege]

I will change the IDS documentation accordingly. Probably the much better way. Thanks for raising attention and making the solution better as a team.

[c0c0n3]

awe, rock on! going to reimplement using base 64 then :-)

[gboege]

IDSA-Documents already changed:

[gboege]

The same of course for the signature part... and additionally mentioning UTF-8 as character Set.

Well done, and quick :-)

[c0c0n3]

implemented by #16.