DCQL förklarat: så begär en verifierare exakt det den behöver från en plånbok

Problemet som DCQL löser

Begära ett reservalternativ: claim_sets

claim_sets listar grupper av uppgifts-id:n i prioritetsordning. Plånboken returnerar den första grupp den helt kan uppfylla med det innehavaren faktiskt har, så att verifieraren slipper skicka två separata förfrågningar för ett exakt fall och ett reservfall.

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "claims": [
        { "id": "reg_no", "path": ["registration_number"] },
        { "id": "legal_name", "path": ["legal_name"] }
      ],
      "claim_sets": [
        ["reg_no", "legal_name"],
        ["legal_name"]
      ]
    }
  ]
}

Här föredrar verifieraren registreringsnummer plus juridiskt namn, men godtar enbart det juridiska namnet om innehavarens intyg inte innehåller någon uppgift om registreringsnummer.

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: legal_name>~<key binding JWT>"
    ]
  }
}

{
  "vct": "urn:eudi:business:company-registration:1",
  "legal_name": "Example Logistics B.V."
}

Kombinera intyg: credential_sets

credential_sets verkar en nivå ovanför claim_sets. Varje post listar options, där varje alternativ är en grupp id:n för intygsfrågor. Plånboken måste uppfylla ett alternativ i varje obligatorisk post, vilket ger verifieraren OCH- och ELLER-logik mellan intyg i en enda begäran.

"credential_sets": [
  { "options": [["company_registration"]] },
  { "options": [["vat_registration"], ["bank_account"]] }
]

Exempel på svar: registrering plus bankkonto

Vad plånboken skickar

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosures>~<key binding JWT>"
    ],
    "bank_account": [
      "<issuer-signed JWT>~<disclosures>~<key binding JWT>"
    ]
  }
}

Uppgifter som verifieraren ser efter validering

{
  "company_registration": {
    "vct": "urn:eudi:business:company-registration:1",
    "registration_number": "12345678",
    "legal_name": "Example Logistics B.V."
  },
  "bank_account": {
    "vct": "urn:eudi:business:bank-account:1",
    "iban": "NL91ABNA0417164300",
    "account_holder": "Example Logistics B.V."
  }
}

Innehavaren har inget intyg om momsregistrering, så plånboken valde det andra alternativet i den andra uppsättningen. Fråge-id:n som inte användes, här vat_registration, saknas helt enkelt i vp_token.

Bara betrodda utfärdare: trusted_authorities

trusted_authorities begränsar en intygsfråga till intyg vars utfärdare backas av en myndighet som verifieraren litar på. Varje post har en typ och en lista med värden: aki för en authority key identifier, etsi_tl för en ETSI-betrodd lista eller openid_federation för ett förtroendeankare i en federation. Plånboken erbjuder bara intyg som matchar.

Exempel: en registrering från en listad utfärdare

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "trusted_authorities": [
        {
          "type": "etsi_tl",
          "values": ["https://ec.europa.eu/tools/lotl/eu-lotl.xml"]
        }
      ],
      "claims": [
        { "id": "reg_no", "path": ["registration_number"] },
        { "id": "legal_name", "path": ["legal_name"] }
      ]
    }
  ]
}

Exempel på svar: bara intyget från den listade utfärdaren

Vad plånboken skickar

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: registration_number>~<disclosure: legal_name>~<key binding JWT>"
    ]
  }
}

Uppgifter som verifieraren ser efter validering

{
  "vct": "urn:eudi:business:company-registration:1",
  "registration_number": "12345678",
  "legal_name": "Example Logistics B.V."
}

Innehavaren hade också ett registreringsintyg från en olistad utfärdare, men plånboken erbjöd det inte. trusted_authorities är ett filter för plånboken, inte en garanti: verifieraren kontrollerar ändå själv utfärdaren mot den betrodda listan när den validerar presentationen.

Matcha ett värde: claims.values

En uppgiftsfråga kan innehålla values, en lista med strängar, heltal eller booleska värden. Plånboken returnerar bara uppgiften när dess typ och värde exakt matchar något av dem, så att en verifierare kan kontrollera ett villkor utan att först begära något annat.

Exempel: bara företag registrerade i Nederländerna eller Belgien

{
  "credentials": [
    {
      "id": "company_registration",
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["urn:eudi:business:company-registration:1"] },
      "claims": [
        { "id": "legal_name", "path": ["legal_name"] },
        {
          "id": "reg_country",
          "path": ["registration_country"],
          "values": ["NL", "BE"]
        }
      ]
    }
  ]
}

Exempel på svar: ett nederländskt företag

Vad plånboken skickar

{
  "vp_token": {
    "company_registration": [
      "<issuer-signed JWT>~<disclosure: legal_name>~<disclosure: registration_country>~<key binding JWT>"
    ]
  }
}

Uppgifter som verifieraren ser efter validering

{
  "vct": "urn:eudi:business:company-registration:1",
  "legal_name": "Example Logistics B.V.",
  "registration_country": "NL"
}

Ett tyskt företags intyg har registration_country "DE", så det uppfyller inte frågan och plånboken har inget att returnera för det. Verifieraren bör ändå kontrollera värdet i de validerade uppgifterna i stället för att förlita sig på plånbokens filtrering.

Var DCQL står i dag

• DCQL definieras i själva OpenID4VP-specifikationen, inte i ett separat dokument, och har ingått i utkastet sedan mekanismen infördes för att ersätta ett tidigare beroende av DIF Presentation Exchange för OpenID4VP-förfrågningar.
• EUDI Wallet Architecture and Reference Framework anger OpenID4VP som presentationsprotokoll och därmed DCQL som den frågemekanism som förlitande parter och plånböcker i ekosystemet förväntas stödja.
• Referensimplementationer av plånböcker och verifierare i programmet EUDI Wallet Reference Implementation har samlats kring DCQL. Nya integrationer av företagsplånböcker som byggs mot OpenID4VP i dag bör därför utgå från DCQL, inte Presentation Exchange, som frågeformat för presentationsbegäranden.

Vanliga frågor

Den här sidan är endast informativ och utgör inte juridisk rådgivning. För auktoritativ vägledning, kontakta OpenID Foundation och Europeiska kommissionen direkt.