Difference between revisions of "DCQL"
From MgmtWiki
(Created page with "==Full Title== ==IIW 2025-04== Tags / links to resources / technology discussed, related to this session: https://docs.google.com/presentation/d/12Tcta_MhupcYhDLci4wtBFJAAb...") |
(→References) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title== | ==Full Title== | ||
| + | Digital Credentials Query Language | ||
==IIW 2025-04== | ==IIW 2025-04== | ||
| Line 9: | Line 10: | ||
Introduction to DCQL | Introduction to DCQL | ||
| − | DCQL became the only query language for OpenID4VP, PE2 got removed to make things simpler, less implementation effort | + | * DCQL became the only query language for OpenID4VP, PE2 got removed to make things simpler, less implementation effort |
| − | limited feature set for simplicity | + | * limited feature set for simplicity |
| − | good implementation feedback so far | + | * good implementation feedback so far |
Purpose | Purpose | ||
| − | purpose is currently optional freetext field | + | * purpose is currently optional freetext field |
| − | worries about phishing attacks (not bufferoverflows etc) | + | * worries about phishing attacks (not bufferoverflows etc) |
| − | purpose in unsigned seems more dangerous | + | * purpose in unsigned seems more dangerous |
| − | purpose in signed requests makes more sense, could be integrated in RP certificate | + | * purpose in signed requests makes more sense, could be integrated in RP certificate |
| − | sign over prose? i.e. put it into KB-JWT? | + | ** sign over prose? i.e. put it into KB-JWT? |
| − | in transaction_data we show and sign RP-chosen text | + | ** in transaction_data we show and sign RP-chosen text |
| − | increases accountability | + | * increases accountability |
| − | 18013-5 defining integers/enums/codes for common use cases, e.g. buy alkohol | + | * 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 may be limited and there are more use cases than codes |
| − | codes are better for being language independent | + | ** codes are better for being language independent |
| − | freetext may be harder to display for Wallets, e.g. max length? | + | * freetext may be harder to display for Wallets, e.g. max length? |
| − | user decision may not be significantly influenced by the purpose string | + | * user decision may not be significantly influenced by the purpose string |
| − | purpose may give guidance why certain credentials are requested | + | ** purpose may give guidance why certain credentials are requested |
| − | unclear if purpose was a requirement by ISO group | + | * unclear if purpose was a requirement by ISO group |
| − | rough consensus to remove it, Brian will do a PR | + | * rough consensus to remove it, Brian will do a PR |
Advanced Features | Advanced Features | ||
| − | currently we only have exact value matching | + | *currently we only have exact value matching |
| − | is there a need for functions, e.g. greater-than, array membership etc.. | + | *is there a need for functions, e.g. greater-than, array membership etc.. |
| − | e.g. matching if nationality is within array | + | **e.g. matching if nationality is within array |
| − | Dimitri: operators look very similar to JSON Schema | + | *Dimitri: operators look very similar to JSON Schema |
| − | current ideas are based on Daniel Fett’s draft | + | **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 | + | *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 | + | *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 | + | *David: matching attribute values across multiple credentials is an important feature |
| − | Gareth: matching names does not work very well in practice | + | **Gareth: matching names does not work very well in practice |
| − | Ahbi + Matteo: strong typing is required for ZKP features | + | *Ahbi + Matteo: strong typing is required for ZKP features |
| − | problem that we have multiple credential formats with different typing | + | **problem that we have multiple credential formats with different typing |
| − | Hicham: be aware that we potentially add lots of complexity | + | **Hicham: be aware that we potentially add lots of complexity |
| − | Paul + Lee: Basic Value matching is important and may add privacy | + | **Paul + Lee: Basic Value matching is important and may add privacy |
| − | Helen: Array matching seems the most important use case | + | *Helen: Array matching seems the most important use case |
| + | ==Solutions== | ||
| + | * 2505-07-25 [https://github.com/openwallet-foundation-labs/dcql-ts DCQL=TS on OWF GitHub] | ||
| + | |||
==References== | ==References== | ||
| + | |||
| + | [[Category: Standard]] | ||
| + | [[Category: Authentication]] | ||
Latest revision as of 18:44, 25 July 2025
Contents
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
- 2505-07-25 DCQL=TS on OWF GitHub
