DCQL - Revision history

Tom: /* References */

2025-07-26T01:44:54Z

‎References

Tom: /* References */

2025-05-27T01:37:27Z

‎References

Tom: /* Full Title */

2025-05-27T01:31:25Z

‎Full Title

Tom at 01:27, 27 May 2025

2025-05-27T01:27:41Z

Tom at 01:19, 27 May 2025

2025-05-27T01:19:58Z

Tom: 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..."

2025-05-27T01:17:34Z

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

New page

==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

==References==

@@ Line 47: / Line 47: @@
 *Helen: Array matching seems the most important use case
 ==References==
 [[Category: Standard]]
 [[Category: Authentication]]

← Older revision		Revision as of 01:37, 27 May 2025
Line 48:		Line 48:

	==References==		==References==
		+
		+	[[Category: Standard]]
		+	[[Category: Authentication]]

← Older revision		Revision as of 01:31, 27 May 2025
Line 1:		Line 1:
	==Full Title==		==Full Title==
		+	Digital Credentials Query Language

	==IIW 2025-04==		==IIW 2025-04==

@@ Line 32: / Line 32: @@
 Advanced Features
 *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==

@@ Line 9: / Line 9: @@
 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 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
--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
-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..
 e.g. matching if nationality is within array