search

openid / OpenID4VP

57 stars 20 forks source link

Introduce new query language (Approach 3) #266

Closed danielfett closed 1 month ago

danielfett commented 2 months ago

This approach uses ids and a separate definition of valid sets of claims/credentials to return.

The draft text has not been adapted yet, let's discuss the JSON examples first!

Text is now updated as well, please review.

List of issues to solve in separate PRs:

Fixes #178 Fixes #249 Fixes #255 (or rather, makes it obsolete) Fixes #193 Fixes #161 (that was the discussion on the requirements for this new language) Fixes #157 (mandatory to implement features of the query language) Fixes #164 Fixes #160 Fixes #148

bc-pi commented 2 months ago

... discuss the JSON examples first!

IMHO this would be so much easier to do if the examples were just inline with the text defining or describing them.

danielfett commented 2 months ago

... discuss the JSON examples first!

IMHO this would be so much easier to do if the examples were just inline with the text defining or describing them.

Not if the text has not been updated anyway...

danielfett commented 2 months ago

Here is a draft how the syntax designed for Transformed Claims could be integrated into this proposal to enable more complex matching:

{
  "expect_credentials": [
    {
      "group": "pid",
      "format": "vc+sd-jwt",
      "expect_meta": {
        "vct_values": [ "https://credentials.example.com/identity_credential" ],
        "credential_signing_alg_values": ["ES256", "ES384"],
        "sd_alg_values": ["SHA-256"]
      },

      "expect_claims": [
        # "traditional" as in the current PR; value/values matching
        {"id": "a", "path": ["last_name"], "value": "Dow"},  

        # apply two functions: calculate years since DOB, check if >= 21; match if result is true
        {"id": "b", "path": ["date_of_birth"], "fn": ["years_ago", ["gte", 21]], "value": true},  

        # apply lower-case conversion, then match
        {"id": "c", "path": ["first_name"], "fn": ["to_lower"], "value": "john"}, 

        # works with 'values' as well
        {"id": "f", "path": ["email"], "fn": ["ends_with"], "values": ["@gmail.com", "@yahoo.com"]} 

        # future extension for ZKP predicates?  
        {"id": "d", "path": ["date_of_birth"], "zkp_fn": ["years_ago", ["gte", 21]]}, 
      ],
      "valid_claim_sets": [
        ["a", "b", "e", "f?"],
        ["a", "c", "d", "e", "f?"]
      ]
    }
  ]
}

@martijnharing @TimoGlastra

danielfett commented 1 month ago

Just to make clear I understand the proposal correctly. In order to request the following info: (portrait AND (zip code OR (city AND state), from an ISO mdl, I would need to do the following?

Yes, your example is correct.

Especially with ISO mdoc, I do see some issues with alg_values and hash_algorithm_values in the expect_meta:

The expect_meta section for ISO mdoc is a TBD that I'd like to leave to the experts — please file changes to the PR as you see fit.

I'm struggeling with things like credential_signing_alg_values, sd_alg_values, alg_values and hash_algorithm_values being included in the expect_meta parameter. Shouldn't these be defined as Verifier Metadata at a higher level? If the wallet knows what the verifier supports in general, it shouldn't really matter what cryptographic algorithms the specific credential supports, right?

updated: also if someone requests a bunch of credentials, this would lead to an unnecessary repetition of the algorithms for each requested credential.

My view on this is that while the Wallet may know what the Verifier supports, this is an opportunity for the Verifier to say "I really only want this particular algorithm to be used here". But let's discuss!

peppelinux commented 1 month ago

May I ask to consider my suggestions made in the Approach 2 if is there something of interest? https://github.com/openid/OpenID4VP/pull/260/files

danielfett commented 1 month ago

Discussed on the call: We'll remove the alg-related matching for now.

danielfett commented 1 month ago

Most important open topics:

Sakurann commented 1 month ago

could we use the same syntax for mdocs and sd-jwt for path? so that it is path: [, ] as opposed to { namespace : "", data_element: ""}?

Sakurann commented 1 month ago

please make it clear that

? - I need this, so don’t return the response if you don’t have it ?? - this is nice to have, send response even if you don’t have it

danielfett commented 1 month ago

please make it clear that

? - I need this, so don’t return the response if you don’t have it ?? - this is nice to have, send response even if you don’t have it

We agreed on the call on the following:

claim — I need this, so don’t return the response without it claim? — I need this, but it may not be in the credential. If it is in the credential, don't return the response without it claim?? — this is nice to have, send response even if you don’t have it

David suggested ?! for the second option and ? for the last.

awoie commented 1 month ago

please make it clear that

? - I need this, so don’t return the response if you don’t have it ?? - this is nice to have, send response even if you don’t have it

We agreed on the call on the following:

claim — I need this, so don’t return the response without it claim? — I need this, but it may not be in the credential. If it is in the credential, don't return the response without it claim?? — this is nice to have, send response even if you don’t have it

David suggested ?! for the second option and ? for the last.

I would be ok with: ? -> nice to have ?! -> required if present

I would prefer: ? -> nice to have ! -> required if present

I would prefer limiting these special functions to ONE character only. Not sure if "!" would be a better option than "?!", or if another character should be used instead. People will get the order wrong and use "?!" or "!?" which could be annoying for some developers.

danielfett commented 1 month ago

We could use ‽ :-)

martijnharing commented 1 month ago

As also mentioned in this comment: https://github.com/openid/OpenID4VP/pull/266/files#r1775413078 optionality should not exist for data elements or credentials but only on a use-case basis. Within satisfying a certain use case, optionality doesn't really makes sense as the user should always provide the minimal information possible to satisfy the particular use case. If there are scenarios where it's in the user interest to provide more information, then that's a different use-case and it should be encoded in the request that way.

tplooker commented 1 month ago

could we use the same syntax for mdocs and sd-jwt for path? so that it is path: [, ] as opposed to { namespace : "", data_element: ""}?

I'm not in favour of this for mDocs, I don't believe it adds any complexity to implementations so would prefer we leave it as is.

tplooker commented 1 month ago

Another observation I had generally is I wonder whether the meta object here adds much in way of value, perhaps we could simplify the structure from 

"credentials": [
    {
      "id": "pid",
      "format": "vc+sd-jwt",
      "meta": {
        "vct_values": ["https://credentials.example.com/identity_credential"]
      },
      "claims": [
        {"path": ["given_name"]},
        {"path": ["family_name"]},
        {"path": ["address", "street_address"]}
      ]
    },
    {
      "id": "other_pid",
      "format": "vc+sd-jwt",
      "meta": {
        "vct_values": ["https://othercredentials.example/pid"]
      },
      "claims": [
        {"path": ["given_name"]},
        {"path": ["family_name"]},
        {"path": ["address", "street_address"]}
      ]
    }
]

To 

"credentials": [
    {
      "id": "pid",
      "format": "vc+sd-jwt",
      "vct_values": ["https://credentials.example.com/identity_credential"]
      "claims": [
        {"path": ["given_name"]},
        {"path": ["family_name"]},
        {"path": ["address", "street_address"]}
      ]
    },
    {
      "id": "other_pid",
      "format": "vc+sd-jwt",
       "vct_values": ["https://othercredentials.example/pid"]
      "claims": [
        {"path": ["given_name"]},
        {"path": ["family_name"]},
        {"path": ["address", "street_address"]}
      ]
    }
]
danielfett commented 1 month ago

As also mentioned in this comment: https://github.com/openid/OpenID4VP/pull/266/files#r1775413078 optionality should not exist for data elements or credentials but only on a use-case basis. Within satisfying a certain use case, optionality doesn't really makes sense as the user should always provide the minimal information possible to satisfy the particular use case. If there are scenarios where it's in the user interest to provide more information, then that's a different use-case and it should be encoded in the request that way.

I'm surprised that this was not brought up earlier... The whole structure would be quite different if we agree on that. Can you please create a new PR with what you propose (I'm not doing a fourth one, sorry)?

tplooker commented 1 month ago

I'm surprised that this was not brought up earlier... The whole structure would be quite different if we agree on that. Can you please create a new PR with what you propose (I'm not doing a fourth one, sorry)?

I've raised #281 against this PR as an attempt to progress this conversation, please review.

Sakurann commented 1 month ago

As also mentioned in this comment: https://github.com/openid/OpenID4VP/pull/266/files#r1775413078 optionality should not exist for data elements or credentials but only on a use-case basis. Within satisfying a certain use case, optionality doesn't really makes sense as the user should always provide the minimal information possible to satisfy the particular use case. If there are scenarios where it's in the user interest to provide more information, then that's a different use-case and it should be encoded in the request that way.

I'm surprised that this was not brought up earlier... The whole structure would be quite different if we agree on that. Can you please create a new PR with what you propose (I'm not doing a fourth one, sorry)?

I am also surprised at the timing and the statement, but I am not sure why it needs to result in another structure. If I understand correctly, the ask is to remove ? from claim_set and credential_set (guess we are still leaving ?! which is very specific to mDL use-case but ok, I will shut up on that). I am ok removing ? options from this PR (open an issue to track it) and merging it as the first version of the NQL and once we have implementation experience we can come back to re-introducing ? or not.

David-Chadwick commented 1 month ago

I have never seen the value of asking the user to optionally provide extra PII. Why would they bother? If I can perform a task or obtain a service by providing items A and B of my PII, why would I also proffer item C as well for no extra benefit to me? If extra benefit is derived from providing item C then this is a different task/service to the original one e.g. to fly to the US provide your name and passport number, but you can enter the business lounge if you also provide your email and postal address. These are essentially different services and neither require optionality.

tplooker commented 1 month ago

I am also surprised at the timing and the statement, but I am not sure why it needs to result in another structure.

Please review the associated PR to understand why.

If I understand correctly, the ask is to remove ? from claim_set and credential_set (guess we are still leaving ?! which is very specific to mDL use-case but ok, I will shut up on that)

I don't believe that is accurate, the feature is useful for any credential that has optional claims regardless of its format, the feature has been defined in a generic manner too so works for SD-JWT and mDocs.

I am ok removing ? options from this PR (open an issue to track it) and merging it as the first version of the NQL and once we have implementation experience we can come back to re-introducing ? or not.

The problem with simply removing optionality without adding the structure I proposed means many important use cases are no longer possible.

tplooker commented 1 month ago

I have never seen the value of asking the user to optionally provide extra PII. Why would they bother? If I can perform a task or obtain a service by providing items A and B of my PII, why would I also proffer item C as well for no extra benefit to me? If extra benefit is derived from providing item C then this is a different task/service to the original one e.g. to fly to the US provide your name and passport number, but you can enter the business lounge if you also provide your email and postal address. These are essentially different services and neither require optionality.

I believe I mostly agree, however in the event you have two usecases that might be serviced in a single flow e.g "proof of identity" is required but "proof of customer loyalty" is optional, there is in effect some level of optionality in the response its just a matter of at what level that optionality is expressed, not a claim or credential level but more at the usecase level, that is what #281 aims to achieve.

jogu commented 1 month ago

I have never seen the value of asking the user to optionally provide extra PII. Why would they bother? If I can perform a task or obtain a service by providing items A and B of my PII, why would I also proffer item C as well for no extra benefit to me? If extra benefit is derived from providing item C then this is a different task/service to the original one e.g. to fly to the US provide your name and passport number, but you can enter the business lounge if you also provide your email and postal address. These are essentially different services and neither require optionality.

There are cases where the credential the user is sharing has information that is not legally required but the user can usefully share providing benefit to the user.

If I need to provide proof of age to buy a knife/alcohol/other restricted item online, I can do that with my driving license. I can also optionally share the address from my driving license to save me having to manually enter the delivery address, but sharing the address on my driving license isn't "necessary" to complete the transaction.

For payment credentials, some have an email address associated with them - sharing the email address when paying isn't necessary, but if the user wants to receive an emailed receipt it's useful.

Yes, they could be done as multiple separate requests, but I suspect the benefit to the user starts to fall away if you do that. An extra check box is fine, redoing the whole flow is a more significant action.

tplooker commented 1 month ago

There are cases where the credential the user is sharing has information that is not legally required but the user can usefully share providing benefit to the user.

Agreed and here is how that can be accomodated in the syntax proposed in #281 

{
  "credentials": [
    {
      "id": "mdl-id",
      "format": "mso_mdoc",
      "meta": {
        "doctype_values": ["org.iso.18013.5.1.mdl"]
      },
      "claims": [
        {
          "id": "given_name",
          "namespace": "org.iso.18013.5.1",
          "claim_name": "given_name"
        },
        {
          "id": "family_name",
          "namespace": "org.iso.18013.5.1",
          "claim_name": "family_name"
        },
        {
          "id": "portrait",
          "namespace": "org.iso.18013.5.1",
          "claim_name": "portrait"
        }
      ]
    },
    {
      "id": "mdl-address",
      "format": "mso_mdoc",
      "meta": {
        "doctype_values": ["org.iso.18013.5.1.mdl"]
      },
      "claims": [
        {
          "id": "resident_address",
          "namespace": "org.iso.18013.5.1",
          "claim_name": "resident_address"
        },
        {
          "id": "resident_country",
          "namespace": "org.iso.18013.5.1",
          "claim_name": "resident_country"
        }
      ]
    },
    {
      "id": "photo_card-id",
      "format": "mso_mdoc",
      "meta": {
        "doctype_values": ["org.iso.23220.photoid"]
      },
      "claims": [
        {
          "id": "given_name",
          "namespace": "org.iso.23220.1",
          "claim_name": "given_name"
        },
        {
          "id": "family_name",
          "namespace": "org.iso.23220.1",
          "claim_name": "family_name"
        },
        {
          "id": "portrait",
          "namespace": "org.iso.23220.1",
          "claim_name": "portrait"
        }
      ]
    },
    {
      "id": "photo_card-address",
      "format": "mso_mdoc",
      "meta": {
        "doctype_values": ["org.iso.23220.photoid"]
      },
      "claims": [
        {
          "id": "resident_address",
          "namespace": "org.iso.23220.1",
          "claim_name": "resident_address"
        },
        {
          "id": "resident_country",
          "namespace": "org.iso.23220.1",
          "claim_name": "resident_country"
        }
      ]
    }
  ],
  "credential_sets": [
    {
      "purpose": "Prove your ID",
      "query_options": [
        [ "mdl-id" ],
        [ "photo_card-id" ]
      ]
    },
    {
      "purpose": "Prove your Address - so you don't have to enter in manually",
      "required": false,
      "query_options": [
        [ "mdl-address" ],
        [ "photo_card-address" ]
      ]
    }
  ]
}

This query basically says you can prove your id from your photo id OR your mdl and optionally decide to prove your address from either your photo id or mdl. Importantly what makes this more intuitive from a UX perspective is the optionality isn't at a per claim or credential level which would be difficult to convey why the RP is asking for two optional attributes on your DL (resident_address, resident_country).

David-Chadwick commented 1 month ago

There are cases where the credential the user is sharing has information that is not legally required but the user can usefully share providing benefit to the user.

A service with an optional benefit can also be represented as two different services, and the user can choose which service they want. Then there is no requirement for optional attributes. BTW your example of buying a knife/alcohol/other restricted item online is not valid in this context, since the address is not optional, it is mandatory since the item must be posted to somewhere. Whether the address comes from the driving license or a utility bill or a self issued credential (equivalent to entering manually) depends upon who the verifier trusts to issue the credential, so would not be modelled as optional information, but rather as different issuers of attributes.
OTOH providing an optional email address for a receipt of an online transaction might appear to be an example of an optional attribute, although this could still be modelled as a transaction with receipt and a transaction without receipt, and the user can choose which service they want before the query is sent to the wallet. If you want to use optional attributes in a query to represent different service levels I suggest this makes the UI very complex for the wallet to handle. How does the wallet know which new service component is being activated by which optional attribute? Rather I think that when the user is interacting with the RP, they first decide which service they want. Then the query asks for all the attributes that are required for this service to be granted, and the wallet chooses the credentials that can match the query. If there are different sets of credentials that can satisfy the RP's query, then the user chooses which set to return.

OR13 commented 1 month ago

In this example:

 {
  "id": "resident_country",
  "namespace": "org.iso.23220.1",
  "claim_name": "resident_country"
 }

is id the machine processable identifier? and claim_name a "display string" ? Having these be the same makes the example less useful... perhaps consider an internationalized sample, where these are different?

tplooker commented 1 month ago

is id the machine processable identifier? and claim_name a "display string" ? Having these be the same makes the example less useful... perhaps consider an internationalized sample, where these are different?

Yes its not suppose to be human meaningful we should probably update the examples in future to have an ID like a GUID to make that clear.

danielfett commented 1 month ago

After quite a bit of back and forth, I made changes to this PR that hopefully find a good compromise between all proposed solutions. Based on Tobias' latest proposals, this is what's in the latest PR:

kept the claim_sets

We discussed the claim_sets syntax on the working group call last Thursday and there was a rough consensus in the room to remove it, but with the open task to find another solution for the real ID use case (previously, the '?!' syntax). I looked into various options, including pushing the feature to the credential_sets level (what we discussed on the call) and adding a property to the claim descriptors. Both are not great. It turns out that the simplest solution is to just keep claim_sets. With the rule that was introduced to oblige wallets to send the first available combination of claims in claim_sets, the claims can just be listed in the right order: "claim_sets": [ ['a', 'real_id'], ['a']] — problem solved.

This syntax is not specific to the real ID use case, but happens to generally solve cases where I don't know ahead of time what claims are available in a credential.

I'm somewhat convinced that this syntax will come in handy again in the future once we talk more about value matching and/or ZKP features.

removed the '?' and '?!' syntax

We don't need the ?! anymore as the real ID use case can be solved as shown above. We also don't need ? anymore as we don't have "really" optional claims in the claim_sets any longer. This should make implementations much simpler.

introduced purpose

As discussed, without prescribing a specific format or content. We can figure that out later.

Examples/Description

I also changed the examples to reflect the new syntax and made some changes to the normative language around the new QL.

nklomp commented 1 month ago

As I also proposed to use the array ordering instead of the syntax I am in favor of the current version.

I would like to mention one thing that I didn't mention the other day. I generally don't like to chuck these logical operators into value strings. It can become problematic to extend in the future, is harder to validate. IMO it would make sense to make objects out of these values. The intent of the query language is to make it easier compared to PE amongst others. But at the same time it its primary purpose is machine interpretation anyway and not human interpretation. Tools will be build to help users to create the queries anyway. There is asymmetry in certain arrays where strings are being used, whilst almost everywhere else objects are being used in arrays. From a mental model I prefer to have the same approach everywhere, even if that means a bit more verbose syntax. The previous usage of "?!" is a consequence of the asymmetry

martijnharing commented 1 month ago

After quite a bit of back and forth, I made changes to this PR that hopefully find a good compromise between all proposed solutions. Based on Tobias' latest proposals, this is what's in the latest PR:

kept the claim_sets

We discussed the claim_sets syntax on the working group call last Thursday and there was a rough consensus in the room to remove it, but with the open task to find another solution for the real ID use case (previously, the '?!' syntax). I looked into various options, including pushing the feature to the credential_sets level (what we discussed on the call) and adding a property to the claim descriptors. Both are not great. It turns out that the simplest solution is to just keep claim_sets. With the rule that was introduced to oblige wallets to send the first available combination of claims in claim_sets, the claims can just be listed in the right order: "claim_sets": [ ['a', 'real_id'], ['a']] — problem solved.

This syntax is not specific to the real ID use case, but happens to generally solve cases where I don't know ahead of time what claims are available in a credential.

I'm somewhat convinced that this syntax will come in handy again in the future once we talk more about value matching and/or ZKP features.

removed the '?' and '?!' syntax

We don't need the ?! anymore as the real ID use case can be solved as shown above. We also don't need ? anymore as we don't have "really" optional claims in the claim_sets any longer. This should make implementations much simpler.

introduced purpose

As discussed, without prescribing a specific format or content. We can figure that out later.

Examples/Description

I also changed the examples to reflect the new syntax and made some changes to the normative language around the new QL.

We should not have options in the claim_sets that are not functionally equivalent from a use-case perspective. e.g. while there may be benefits to the user from a privacy perspective to return one element instead of another (age_over_18 vs date_of_birth), whichever you return you will still get the use-case / purpose. The updated language mandates the wallet to adhere to the stated order of preference, which has a number of downsides:

Which data elements to return isn't/shouldn't be part of the security model. The RP typically can't know if the wallet actually returns the first element that it can return. There are potentially ways where this can be ensured but that has very significant implications on credential formats, key binding, wallet certification etc This means that the RP should still see the order of preference as a best effort mechanism. Which is much better to call out explicitly in the specification to make sure that RP's realize that they cannot rely on this order of preference from a security mechanism.

There may be cases where the wallet has a preference for one data element over the other. (e.g. portrait vs on_device_authentication). With the updated language the wallet would no longer be permitted to make such an assessment, even if they ultimately both achieve the same goal.

Some of these concerns are also shared with the conditional data element. But it's better to specifically deal with that use case than to complicate the security model of a lot more transactions. For the conditional element we can add clarifying language along the lines of: "Note because from a security perspective the RP cannot rely on the wallet to be truthful about the presence of data elements on the wallet, this parameter can only be meaningfully used if the RP knows through an out-of-band mechanism whether an wallet must have certain element or not." I don't like the conditional element for this reason, but prefer to keep this awkwardness for the conditional data element only and not have the same logic apply to the much more generic claim_sets logic. Also, with the presence of issuer selection (still to be added) there is a possibility that we don't need the conditional element. Which would make it even cleaner.

My proposal would therefore be to:

As part of the implementation feedback (which can include asking the ISO WG for feedback) we can then determine if we need to keep the conditional elements or if the issuer selection mechanism covers it sufficiently.

Sakurann commented 1 month ago

char hat on. re-requesting review from everyone who had previously commented/reviewed, including those who already approved, since a lot has been changed. This is a version we are looking to merge and go to Implementers Draft after a WG call tomorrow, on Tue Oct-22nd. If anyone wants to see any substantive changes to this PR, please do a PR on PR - no guarantee we will be able to merge it before ID, but we might be able to merge it first thing after WGLC.

javereec commented 1 month ago

Looks good.

One item that might be worth considering when thinking about parity with QL defined ISO 18013-5 is the inclusion of something like intent_to_retain. The obvious place to add this in this proposal would be in the claims query object.

danielfett commented 1 month ago

We should not have options in the claim_sets that are not functionally equivalent from a use-case perspective. e.g. while there may be benefits to the user from a privacy perspective to return one element instead of another (age_over_18 vs date_of_birth), whichever you return you will still get the use-case / purpose. The updated language mandates the wallet to adhere to the stated order of preference, which has a number of downsides.

Which data elements to return isn't/shouldn't be part of the security model. The RP typically can't know if the wallet actually returns the first element that it can return. There are potentially ways where this can be ensured but that has very significant implications on credential formats, key binding, wallet certification etc This means that the RP should still see the order of preference as a best effort mechanism. Which is much better to call out explicitly in the specification to make sure that RP's realize that they cannot rely on this order of preference from a security mechanism.

I added security considerations to say that the Verifier MUST NOT rely on the Wallet for enforcing any of the constraints.

I propose that we discuss your other concerns after this PR has been merged — I don't quite follow all of them.

jogu commented 1 month ago

Speaking as a co-chair:

Just a reminder of Kristina's comment above:

This is a version we are looking to merge and go to Implementers Draft after a WG call tomorrow, on Tue Oct-22nd. If anyone wants to see any substantive changes to this PR, please do a PR on PR - no guarantee we will be able to merge it before ID, but we might be able to merge it first thing after WGLC.

Any comments that don't have a PR/suggested change or otherwise aren't resolvable today are likely to be turned into issues at the WG call later today (the final decision is for the working group to make via rough consensus). As agreed on Thursday's working group call, we need to merge an initial version for many reasons, including publishing an implementer's draft and so people can start testing and we can start dealing with some of the missing features in separate PR. We do expect there will be breaking changes made over the next few months as implementors try implementing this.

Sakurann commented 1 month ago

@javereec please open an issue to add intent_to_retain to this new query language.

Sakurann commented 1 month ago

@martijnharing Making the order of preference in claim_sets mandatory is meant to achieve exactly what you are trying to achieve with introducing a "conditional" parameter. preference in claim_sets can help more use-cases (like the age one) and I would like to avoid introducing a mechanism (like "conditional") that optimizes for a very specific use-case (in this case "real id"). I also don't understand how the current approach with the preference in claim_sets complicates a security posture. Agree with Daniel's comment above that we need to more time to discuss this and that probably should be done after this PR is merged.

danielfett commented 1 month ago

I don't see a way to filter on conditional data, has this been excluded intentionally?

For example, requiring that an age field is over 21 is incredibly useful and prevents unnecessary disclosure.

If I have a credential and I'm 20 then I should not need to send the credential (or a subset of its fields) when I could simply determine that I should send nothing.

Without these types of conditionals the query language promotes over-identification.

This is not part of this PR, but there's a plan how to do it — we can use the "transformed claims" syntax from "Advanced Syntax for Claims" from the OpenID eKYC working group.

danielfett commented 1 month ago

I would prefer having the format specific parameters defined in Appendix B instead of defining mdoc + SD-JWT VC there, but that's not a blocker for me to merge this important piece forward

We can easily move these later with an editorial PR.

danielfett commented 1 month ago

I think we should define a better name for the query language; somewhat following @decentralgabe's proposal above, I propose Digital Credential Query Language (DCQL, pronounced Dackel).

jogu commented 1 month ago

Discussed on working group call yesterday - there was unanimous agreement to merge this once Daniel's suggested changes for naming are added (which they have been), and to open issues for all items that still need further discussion. To follow the WG's consensus we will dismiss the 'request for changes' and merge.

This is very much a first version, but well over 200 comments it is very difficult to have productive discussions on this PR, and having focussed issues and PRs will make progress easier and make sure we can track items, get consensus and close them off. For clarity we can (and very likely will) make breaking changes to the query language between now and the spec going final. Nothing is being set in stone by merging this.

It would be a great help to the chairs if people can make sure there are issues open for any unaddressed comments they have made - many thanks to those of you that have already done that! We will try to cover at least some of these issues at the hybrid meeting next week.

Many thanks to Daniel for all his hard work on this, and thanks to everyone that has provided feedback and suggestions that have helped improve the proposal - all the time that has been spent on this is greatly appreciated.