DCQL w pigułce: jak weryfikator prosi portfel dokładnie o to, czego potrzebuje

Problem, który rozwiązuje DCQL

Wariant rezerwowy: claim_sets

claim_sets wymienia grupy identyfikatorów atrybutów w kolejności preferencji. Portfel zwraca pierwszą grupę, którą może w pełni spełnić na podstawie tego, co faktycznie posiada posiadacz, więc weryfikator nie musi wysyłać dwóch osobnych żądań: dla wariantu dokładnego i rezerwowego.

{
  "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"]
      ]
    }
  ]
}

Tutaj weryfikator woli numer rejestrowy wraz z nazwą prawną, ale zaakceptuje samą nazwę prawną, jeśli poświadczenie posiadacza nie zawiera atrybutu z numerem rejestrowym.

{
  "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."
}

Łączenie poświadczeń: credential_sets

credential_sets działa poziom wyżej niż claim_sets. Każdy element wymienia options, gdzie każda opcja jest grupą identyfikatorów zapytań o poświadczenia. Portfel musi spełnić jedną opcję z każdego wymaganego elementu, co daje weryfikatorowi logikę AND i OR dla wielu poświadczeń w jednym żądaniu.

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

Przykładowa odpowiedź: rejestracja i rachunek bankowy

Co wysyła portfel

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

Atrybuty widoczne dla weryfikatora po walidacji

{
  "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."
  }
}

Posiadacz nie ma poświadczenia rejestracji VAT, więc portfel wybrał drugą opcję drugiego zestawu. Identyfikatory zapytań, które nie zostały użyte, tutaj vat_registration, po prostu nie występują w vp_token.

Tylko zaufani wystawcy: trusted_authorities

trusted_authorities zawęża zapytanie do poświadczeń, których wystawca jest wspierany przez podmiot uznawany przez weryfikatora za zaufany. Każdy element ma type i listę values: aki dla identyfikatora klucza urzędu (authority key identifier), etsi_tl dla zaufanej listy ETSI lub openid_federation dla kotwicy zaufania federacji. Portfel proponuje wyłącznie pasujące poświadczenia.

Przykład: rejestracja od wystawcy z listy

{
  "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"] }
      ]
    }
  ]
}

Przykładowa odpowiedź: tylko poświadczenie wystawcy z listy

Co wysyła portfel

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

Atrybuty widoczne dla weryfikatora po walidacji

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

Posiadacz miał też poświadczenie rejestracji od wystawcy spoza listy, ale portfel go nie zaproponował. trusted_authorities to filtr dla portfela, a nie gwarancja: weryfikator i tak sam sprawdza wystawcę na zaufanej liście podczas walidacji prezentacji.

Dopasowanie wartości: claims.values

Zapytanie o atrybut może zawierać values, listę ciągów znaków, liczb całkowitych lub wartości logicznych. Portfel zwraca atrybut tylko wtedy, gdy jego typ i wartość dokładnie odpowiadają jednej z nich, dzięki czemu weryfikator może sprawdzić warunek bez wcześniejszego proszenia o cokolwiek innego.

Przykład: tylko spółki zarejestrowane w Holandii lub Belgii

{
  "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"]
        }
      ]
    }
  ]
}

Przykładowa odpowiedź: spółka holenderska

Co wysyła portfel

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

Atrybuty widoczne dla weryfikatora po walidacji

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

Poświadczenie spółki niemieckiej ma registration_country "DE", więc nie spełnia zapytania i portfel nie ma dla niego nic do zwrócenia. Weryfikator powinien mimo to sprawdzić wartość w zwalidowanych atrybutach, zamiast polegać na filtrowaniu przez portfel.

Obecny status DCQL

• DCQL jest zdefiniowany w samej specyfikacji OpenID4VP, a nie w osobnym dokumencie, i jest częścią wersji roboczej od czasu wprowadzenia tego mechanizmu w miejsce wcześniejszej zależności od DIF Presentation Exchange w żądaniach OpenID4VP.
• EUDI Wallet Architecture and Reference Framework określa OpenID4VP jako protokół prezentacji, a wraz z nim DCQL jako mechanizm zapytań, który mają obsługiwać strony ufające i portfele w ekosystemie.
• Referencyjne implementacje portfeli i weryfikatorów w programie EUDI Wallet Reference Implementation zbiegły się na DCQL, dlatego nowe integracje portfeli biznesowych budowane dziś w oparciu o OpenID4VP powinny zakładać DCQL, a nie Presentation Exchange, jako format zapytań w żądaniach prezentacji.

Najczęściej zadawane pytania

Ta strona ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. Wiążących wskazówek należy szukać bezpośrednio w OpenID Foundation i Komisji Europejskiej.