Enhancement: Specifying own certificate-fingerprints in the DAT request

[tmberthold]

To prevent your own DAT from being copied by other foreign connectors, it would be useful to have the option enabled by default of being able to note your own HTTPS-certificate-fingerprints (or whatever identifier) used in the DAT request. These could then be included in the issued DAT in the transportSha... claim (or other) in the issued DAT. The message-receiving connectors could then check whether the DAT was used by a valid connection which was allowed to use the DAT.

If there is already a standardized way to do this, I would ask for a step-by-step guideline.

[bellebaum]

There is currently no standardized way within the IDS ecosystem. I am also not aware of any OAuth standards that aim to do this. You can do it with Omejdn though.

How to do it using Omejdn

Omejdn implements this draft, which allows requesting attributes with custom values using the claims parameter, provided that the resource owner (the client/connector in IDS) has an attribute like this:

- key: transportCertsSha256
  value: <defaultValue>
  dynamic: true

You can then add an additional claims parameter to the request with the following value:

{
  "access_token": {
    "transportCertsSha256": {
      "value": <desiredValue>
    }
  }
}

This is this is not part of the client_assertion JWT used for authentication, but a separate parameter.

Alternatives

There are currently no plans to standardize this behavior, and different implementations exist (I seem to remember that @jlangkau has built something as well?), but doing it this way ensures a certain level of compatibility with existing standards (in fact, this is very close to the existing OpenID claims parameter). We could of course build our own solution, but in doing so we might loose the flexibility in choosing software to use as the DAPS.

Documentation of such a feature

A step by step guide in the DAPS repo may not be all that useful as long as no standard within the IDS exists. For now, I am working on better documentation for Omejdn that will probably include this feature. I assume that other implementations will have their own documentation.

Once (If ever) IDS has standardized this, there will probably be documentation in IDS-G for the network traffic and in this Repo for the necessary Omejdn configuration.

---

For now, it might make sense to keep this issue open as reference for any discussions.

[HeinrichPet]

Once (If ever) IDS has standardized this, there will probably be documentation in IDS-G for the network traffic and in this Repo for the necessary Omejdn configuration.

I would appreciate it if AISEC would make a proposal for IDS-G-pre that describes how such claims are created and validated.

[bellebaum]

@HeinrichPet The proposal is linked above. I will request you for a review as well