Difference between revisions of "DCQL"
(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...") |
|||
| Line 9: | Line 9: | ||
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 | ||
Revision as of 18:19, 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
