FIWARE / VCVerifier

A software component that provides the necessary Relying Party endpoints required for authentication.
Apache License 2.0
0 stars 6 forks source link

VCVerifier returns Data Access Token with $DID placeholder #43

Open sebplorenz opened 1 month ago

sebplorenz commented 1 month ago

Hi, in my setup I'm requesting a Data Access Token using the following Verifier endpoint: http://verifier.abc/services/data-service/token The response looks like this:

{
  "aud": [
    "data-service"
  ],
  "client_id": "${DID}",
  "exp": 1722321344,
  "iss": "${DID}",
  "kid": "uqOP3gSXosLWgvG7etmIREsdxkYA3YM52O7FrWDghCc",
  "sub": "",
  "verifiableCredential": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1"
    ],
    "credentialSubject": {
      "email": "admin@provider.org",
      "roles": [
        {
          "names": [
            "ADMIN"
          ],
          "target": "did:key:zDnaezHLjbJWWkWcFLowhrCZYkpRcFPMG4nTHns8YehVNGz6M"
        }
      ]
    },
    "id": "urn:uuid:4d0f9980-2e94-4a0a-9710-de8f8ffec925",
    "issuanceDate": "2024-07-29T14:38:02Z",
    "issuer": "did:key:zDnaezHLjbJWWkWcFLowhrCZYkpRcFPMG4nTHns8YehVNGz6M",
    "type": [
      "NaturalPersonCredential"
    ]
  }
}

The client_id and the iss contain the $DID placeholder. I'm sure this has something to do with my setup and maybe I'm sending a wrong request. But it would be nice to get an error message here that points me to the problem.

The request contains the following vp_token (already base64 decoded here) and it contains all DIDs (I would say)

eyJhbGciOiJFUzI1NiIsICJ0eXAiOiJKV1QiLCAia2lkIjoiZGlkOmtleTp6RG5hZWtSTDNqNmsxSER5SFFSYm9RQmJQQnNGd3d4b2NGd3pVU2FoOWRHODRnaXE2In0.eyJpc3MiOiAiZGlkOmtleTp6RG5hZWtSTDNqNmsxSER5SFFSYm9RQmJQQnNGd3d4b2NGd3pVU2FoOWRHODRnaXE2IiwgInN1YiI6ICJkaWQ6a2V5OnpEbmFla1JMM2o2azFIRHlIUVJib1FCYlBCc0Z3d3hvY0Z3elVTYWg5ZEc4NGdpcTYiLCAidnAiOiB7CiAgICAiQGNvbnRleHQiOiBbImh0dHBzOi8vd3d3LnczLm9yZy8yMDE4L2NyZWRlbnRpYWxzL3YxIl0sCiAgICAidHlwZSI6IFsiVmVyaWZpYWJsZVByZXNlbnRhdGlvbiJdLAogICAgInZlcmlmaWFibGVDcmVkZW50aWFsIjogWwogICAgICAgICJleUpoYkdjaU9pSkZVekkxTmlJc0luUjVjQ0lnT2lBaVNsZFVJaXdpYTJsa0lpQTZJQ0prYVdRNmEyVjVPbnBFYm1GbGVraE1hbUpLVjFkclYyTkdURzkzYUhKRFdsbHJjRkpqUmxCTlJ6UnVWRWh1Y3poWlpXaFdUa2Q2TmswaWZRLmV5SnVZbVlpT2pFM01qSXlOak00T0RJc0ltcDBhU0k2SW5WeWJqcDFkV2xrT2pSa01HWTVPVGd3TFRKbE9UUXROR0V3WVMwNU56RXdMV1JsT0dZNFptWmxZemt5TlNJc0ltbHpjeUk2SW1ScFpEcHJaWGs2ZWtSdVlXVjZTRXhxWWtwWFYydFhZMFpNYjNkb2NrTmFXV3R3VW1OR1VFMUhORzVVU0c1ek9GbGxhRlpPUjNvMlRTSXNJblpqSWpwN0luUjVjR1VpT2xzaVRtRjBkWEpoYkZCbGNuTnZia055WldSbGJuUnBZV3dpWFN3aWFYTnpkV1Z5SWpvaVpHbGtPbXRsZVRwNlJHNWhaWHBJVEdwaVNsZFhhMWRqUmt4dmQyaHlRMXBaYTNCU1kwWlFUVWMwYmxSSWJuTTRXV1ZvVms1SGVqWk5JaXdpYVhOemRXRnVZMlZFWVhSbElqb3hOekl5TWpZek9EZ3lOekE0TENKamNtVmtaVzUwYVdGc1UzVmlhbVZqZENJNmV5SnliMnhsY3lJNlczc2libUZ0WlhNaU9sc2lRVVJOU1U0aVhTd2lkR0Z5WjJWMElqb2laR2xrT210bGVUcDZSRzVoWlhwSVRHcGlTbGRYYTFkalJreHZkMmh5UTFwWmEzQlNZMFpRVFVjMGJsUklibk00V1dWb1ZrNUhlalpOSW4xZExDSmxiV0ZwYkNJNkltRmtiV2x1UUhCeWIzWnBaR1Z5TG05eVp5SjlMQ0pBWTI5dWRHVjRkQ0k2V3lKb2RIUndjem92TDNkM2R5NTNNeTV2Y21jdk1qQXhPQzlqY21Wa1pXNTBhV0ZzY3k5Mk1TSmRmWDAuZmk5Mk1VdlRWQ1lHUUtCWDE2UW5iai1GazlMRjNVLXk2bUc3TWxIek1iRFFicmphSmVyaEFhc1AzUnU4czQtV0lsdHE4MzBaX0FNTEtYcDRoM0JXZ3ciCiAgICBdLAogICAgImhvbGRlciI6ICJkaWQ6a2V5OnpEbmFla1JMM2o2azFIRHlIUVJib1FCYlBCc0Z3d3hvY0Z3elVTYWg5ZEc4NGdpcTYiCiAgfX0.MEYCIQDWii6RN673n8EIldgvVgy3qYPYAHvDUXAf-Tt5DqL5wAIhAOFNR91588SazEQRspDNPfmDEb0_jBm49ernPf3_S2zw

That makes two questions/issues:

  1. Why do I have a placeholder in the response?
  2. The Verifier should return an error if a valid Data Access Token cannot be created (containing an error message pointing to the reason).

Thanks in advance!

sebplorenz commented 1 month ago

Ah ok, from the Verifier Logs:

time="2024-07-30T07:03:06Z" level=info msg="Will read config from /alternative-conf/server.yaml"                                                         │
│ {"level":"info","msg":"Configuration is: {\"Server\":{\"Host\":\"http://verifier.bla\",\"Port\":3000,\"TemplateDir\":\"views/\",\"StaticDir\" │
│ :\"views/static\"},\"Verifier\":{\"Did\":\"${DID}\",\"TirAddress\":\"http://tir-ta.bla\",\"TirCacheExpiry\":30,\"TilCacheExpiry\":30,\"Sessio │
│ nExpiry\":30,\"PolicyConfig\":{\"DefaultPolicies\":null,\"CredentialTypeSpecificPolicies\":null},\"ValidationMode\":\"none\",\"KeyAlgorithm\":\"RS256\"} │
│ ,\"Logging\":{\"Level\":\"DEBUG\",\"JsonLogging\":true,\"LogRequests\":true,\"PathsToSkip\":[\"/metrics\",\"/health\"]},\"ConfigRepo\":{\"ConfigEndpoint │
│ \":\"http://credentials-config-service:8080\",\"Services\":null,\"UpdateInterval\":30},\"M2M\":{\"AuthEnabled\":false,\"KeyPath\":\"\",\"CredentialPath\ │
│ ":\"\",\"ClientId\":\"\",\"VerificationMethod\":\"JsonWebKey2020\",\"SignatureType\":\"JsonWebSignature2020\",\"KeyType\":\"RSAPS256\"}}","time":"2024-0 │
│ 7-30T07:03:06Z"}

Obviously, the DID is set to "${DID}" in the config. Maybe the Verifier should check if its own DID starts with "did:"?