Difference between revisions of "DCQL"
From MgmtWiki
| Line 32: | Line 32: | ||
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 |
==References== | ==References== | ||
Revision as of 18:27, 26 May 2025
Full Title
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
