International-Data-Spaces-Association / omejdn-daps

Open Source implementation of the Dynamic Attribute Provisioning Service based on http://github.com/Fraunhofer-AISEC/omejdn-server
Apache License 2.0
5 stars 10 forks source link

Not working DAT request #2

Closed spetrac closed 2 years ago

spetrac commented 2 years ago

The following DAT request will never work with the current omejdn-daps implementation:

https://github.com/International-Data-Spaces-Association/omejdn-daps/blob/b369ffbaeed4184cb5a32c99056d71c15c248902/README.md#L171-L177

It will throw the following error: Tried : Invalid audience. Expected http://localhost:4567, received https://api.localhost

See https://github.com/International-Data-Spaces-Association/IDS-G-pre/issues/63 for more information on the problems regarding audience and scope.

spetrac commented 2 years ago

Just for reference, here is the decoded payload of the DAT request from the example:

{
  "iss": "democonnector1",
  "sub": "democonnector1",
  "exp": 1548785386,
  "nbf": 1548781786,
  "iat": 1548781786,
  "aud": "https://api.localhost"
}

I would suggest changing it to something that works with the default configuration of the daps, like:

{
  "iss": "testClient",
  "sub": "testClient",
  "exp": 4102444800,
  "nbf": 1262304000,
  "iat": 1262304000,
  "aud": "http://localhost:4567"
}
schanzen commented 2 years ago

The example JWT in the client_assertion field is just that, an example. It should not be used in an actual request. We could remove this example token from the README and replace it with a placeholder or add an even stronger note saying that the example should not be copy/pasted as-is.

The suggested fix is not ideal as the token will eventually expire. But even worse, the token is signed with a private key that does not exist anywhere/anymore. It was created for the sole purpose of creating this example.

spetrac commented 2 years ago

I completely understand the abstraction level and it was no problem for me when implementing a client. However this is only a suggestion to generate meaningful documentations and that it may lead to confusion, if the decoded _clientassertion and _accesstoken does not make sense. These are in fact not just random strings and should therefore contain an actual example request and align to the daps specification as well. Maybe you could also display the decoded tokens to help implementers follow alogn the examples.

schanzen commented 2 years ago

I have updated the readme with further informaton on the assertion and parameters.