DCQL

From MgmtWiki
Jump to: navigation, search

Full Title

Digital Credentials Query Language

IIW 2025-04

Tags / links to resources / technology discussed, related to this session:

https://docs.google.com/presentation/d/12Tcta_MhupcYhDLci4wtBFJAAbNLSqp_g3Cy3MG1dr0/edit?usp=sharing

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Introduction to DCQL

  • DCQL became the only query language for OpenID4VP, PE2 got removed to make things simpler, less implementation effort
  • limited feature set for simplicity
  • good implementation feedback so far

Purpose

  • purpose is currently optional freetext field
  • worries about phishing attacks (not bufferoverflows etc)
  • purpose in unsigned seems more dangerous
  • purpose in signed requests makes more sense, could be integrated in RP certificate
    • sign over prose? i.e. put it into KB-JWT?
    • in transaction_data we show and sign RP-chosen text
  • increases accountability
  • 18013-5 defining integers/enums/codes for common use cases, e.g. buy alkohol
    • codes may be limited and there are more use cases than codes
    • codes are better for being language independent
  • freetext may be harder to display for Wallets, e.g. max length?
  • user decision may not be significantly influenced by the purpose string
    • purpose may give guidance why certain credentials are requested
  • unclear if purpose was a requirement by ISO group
  • rough consensus to remove it, Brian will do a PR

Advanced Features

  • currently we only have exact value matching
  • is there a need for functions, e.g. greater-than, array membership etc..
    • e.g. matching if nationality is within array
  • Dimitri: operators look very similar to JSON Schema
    • current ideas are based on Daniel Fett’s draft
  • things will be added to OpenID4VP 1.1, as 1.0 ship is sailing in the next days
  • we should be careful to not add too many features, as the niceness of DCQL is its consensus feature set and still easy-to-implement
  • David: matching attribute values across multiple credentials is an important feature
    • Gareth: matching names does not work very well in practice
  • Ahbi + Matteo: strong typing is required for ZKP features
    • problem that we have multiple credential formats with different typing
    • Hicham: be aware that we potentially add lots of complexity
    • Paul + Lee: Basic Value matching is important and may add privacy
  • Helen: Array matching seems the most important use case

Solutions

References