Appreciate you putting this proposal together @danielfett, as I shared in the hackmd version that preceded this, I had the following feedback.

Supporting algorithm negotiation per credential request I'm still not in favour of, as I have outlined here I'm yet to understand a usecase where this is required rather then handling algorithm negotiation at a wallet metadata level.

The syntax around alternative claims here is quite difficult to understand, for the following reasons

1. IIUC each claim object becomes polymorphic? e.g describing this as a type in a language like typescript would look like

type ClaimRequest = {
   path: string;
} | {
  required: number;
  from: ClaimRequest[]
}

Which could be difficult to parse in other programming languages that don't support union types.

It also creates situations where the syntax becomes ambiguous to a parser, for example how would I parse the following and what would it mean? Am I asking for last_name OR zip_code OR city and state?

{
  "credentials": {
    "my_cred_1": {
      "format": "vc+sd-jwt",
      "vc+sd-jwt": {
          "vct": "https://credentials.example.com/identity_credential",
          "alg_values": ["ES256", "ES384"],
          "hash_alg_values": ["SHA-256"]
      },
      "purpose": "give me the credential",
      "claims": [
        { 
          "path": ["last_name"] 
          "required": 1, 
          "from": [ 
            { "path": [ "zip_code" ] }, 
            {
              "required": 2,
              "from": [
                { "path": [ "city" ] },
                { "path": [ "state" ] }
              ]
            }
          ] 
        }
      ]
    }
  }
}

2. I would perhaps question how many usecases exist where the value of required > 1. I understand the example you have provided but how many usecases do we expect that require this feature, because if it is very small, then simpler syntaxes, like what were discussed at IIW can be used which can reduce implementation complexity.

1. IIUC each claim object becomes polymorphic? e.g describing this as a type in a language like typescript would look like

type ClaimRequest = {
   path: string;
} | {
  required: number;
  from: ClaimRequest[]
}

These would be two different types of objects. If that doesn't map well in the language of choice, it could be one object with three properties that are mutually exclusive.

It also creates situations where the syntax becomes ambiguous to a parser, for example how would I parse the following and what would it mean? Am I asking for last_name OR zip_code OR city and state?

The shown example would be illegal. Either path is provided or (required and from).

2. I would perhaps question how many usecases exist where the value of required > 1. I understand the example you have provided but how many usecases do we expect that require this feature, because if it is very small, then simpler syntaxes, like what were discussed at IIW can be used which can reduce implementation complexity.

The point is that "required > 1" comes essentially for free. It's a generalization of "and" and "or" operators which you would need otherwise. After having iterated through a couple of options, I doubt that the syntax becomes simpler when omitting this feature. It might become simpler when removing the functionality of being able to express "and" and "or" with arbitrary nesting.

I got this answered out of band, so I figured others would have this question too:

In case you are wondering, the list of requirements that this proposal is constrained by is here: #157 (comment)

In case you are wondering too, here is a list of use cases that this proposal is constrained by.

Note to myself: To cover #193, the vct in the format-specific parameters for SD-JWT should not mean a perfect match, but that a credential of this type or a type inheriting from this should be deliviered. If required, both exact matching and inheritance matching could be supported.

I think what has been coming up as a feedback is whether it should be a different syntax between credential formats depending on how they handle types, which is a current design where mdoc have "doctype" and "namespace" claim, while other credential formats only have "type". I think suggestion has been, not to have something specific to mdoc and try have the same syntax.

I am opposed to any request to the user that does not clearly explain the who the verifier is and what data is required in terms that can be displayed to the user. Here is an alternate proposal. https://docs.google.com/document/d/1keHesvQHrCdbNPavI3imleBm4i9ymXM_/edit?usp=sharing&ouid=109794657323597753486&rtpof=true&sd=true
it includes this link to the format
https://docs.google.com/document/d/1n7HobJ6QTsNld5rn1uuIiNw0A__L44ug/edit?usp=sharing&ouid=109794657323597753486&rtpof=true&sd=true

Discussed on today's WG call; we seemed to have consensus around moving forwards with a PR that adds text that covers examples 1-5 into the VP spec, that would not be merged until after the ID3 vote is underway for the version with the browser API changes incorporated (although some members did express a desire to move quicker).

One outstanding question we should get consensus on: what parameter name should we use for passing the new query language to the wallet? Kristina opened this issue for that: #211

@marcoscaceres @samuelgoto please put your comments here, if any, otherwise @danielfett will proceed with a PR as-is and we can bikeshed in the PR.

@marcoscaceres @samuelgoto please put your comments here, if any, otherwise @danielfett will proceed with a PR as-is and we can bikeshed in the PR.

The main feedback I've given in the past has been to optimize the syntax for the most common cases, rather than the exceptions. Specifically, I think that it is going to be far more common to request a single credential rather than multiple, so I'd make that case as concise as we can possibly make.

I'll comment directly in the PR.