A Relying Party may only want to validate that a Verifiable Credential exists or that a specific attestation within a Verifiable Credential exists, which is an important distinction from a privacy perspective. Not all Relying Parties will want all attestations within a Verifiable Credential.

This spec is expressive to ask for a VC with a specific attestation to fulfill their requirements but the user is also under the obligation to send all attestations for that given Verifiable Credential. Those attestations may include PII and be toxic for the Relying Party to receive and be irrelevant for the user to share.

Example:
As a rental community Relying Party, I would like to validate the schema of bank_credentials.json. This schema includes the attestation of is_bank_account = true but it also includes very private data that does not need to be shared like routing_number, account_number etc. As a Relying Party I want to see the is_bank_account attestation but none of the other attestations.

With that example being stated, I am proposing a flag that goes in the constraints (or where ever is technically the most accurate to solve this issue) that would ask for certain fields to be excluded and other fields to be included. Implementation question: what happens if a attestation does not have a include or exclude flag?

This would make the intentions and full requirements of the Relying Party known to the Client. The Client would then be able to surface a clean permission request for the user to make a decision on. The Client should have a binary decision to make. Remove the 'exclude' attestations and add the 'include' attestations to the Presentation or the request will fail.

In section 4, this sentence is problematic:

If no submission_requirement is present, all inputs listed in the input_descriptor array are required for submission

The element called "input_descriptor" is an object. The element called "input_descriptors" is an array. Therefore the sentence listed above should be corrected to refer to the array in question as the "input descriptors array".

The specification sometimes uses the term “Verifiable Credentials” when what’s meant is verified/verifiable claims that may or may not be in W3C Verifiable Credentials format. That terminology usage will cause endless and unnecessary confusion. We owe it to those reading our specs and those we interact with to use terminology that brings clarity and understanding and guide them towards doing the same.

No matter how we might intended it to be heard, the term “Verifiable Credentials” will essentially always make people think we’re talking about the W3C Verifiable Credentials data structure. So that’s not a workable term for the generic concept of verified claims.

On a call, Daniel suggest simply “Credentials”. The problem with that is that “Credentials” already has a meaning in the identity/security community, in which things like passwords, smart cards, OTPs, PINs, etc. are credentials. (Along these lines, W3C has a Credential Management spec https://www.w3.org/TR/credential-management-1/ and WebAuthn https://w3c.github.io/webauthn/ is an API for “Public Key Credentials”.)

I could live with any of these terms for the generic concept:
• Verified Claims (already in widespread use)
• Verifiable Claims
• Verified Assertions (borrowing from SAML terminology)
• Verifiable Assertions

Let’s discuss among ourselves which we prefer. But please, let’s apply our editing skills and tact to steer people towards using accurate language.

Terminology matters.

It has a complicated syntax that creates labels that other parts of the syntax refer to. The code to operate on that state machine won't be trivial. Please find ways to entirely eliminate the labels.

Making this an array will allow for both a singular pick capability and a flat series of group-based requirements.

As raised in #18

// TODO: how do you require that banking input 1 and banking
// input 2 both have the same credential subject (e.g., same
// primary account holder)?

If values from two different credentials are requested, the verifier should be able to specify that the attributes must have the same credential subject, or to specify the credential subject for each requested attribute.

The introduction needs to explain that this intended to be independent of the particular claims format used to represent the verified claims.  For instance, it should explicitly say that both VCs and JWTs with verified claims can be requested with this spec.

The current proof presentation describes the link between input_descriptors and the input_selection via a set-based rule mechanism e.g. "Satisfy all of set A", "Pick # of set B".

This requires all input_descriptors to be assigned to one or more sets.

An alternative approach to the set-based requirement description could a a boolean algebra approach where input_descriptors are atomic elements describing the input elements that can be identified uniquely ('e.g. "id", "routing_number"') and input_selection describes a boolean algebra like.

[
{
"and": [ "routing_number", "account_number", "idToken"]
},
{
"or": [ "idCard", "passport" ]
}
]

This is just a dummy boolean algebra system. I feel there might be good ones out there already. We should use the same on that we use to represent constraints on individual input_descriptors.
E.g. also see https://stackoverflow.com/questions/20737045/representing-logic-as-data-in-json

In the case of a presentation definition:

      "constraints": {
        "fields": [
          {
            "path": ["$.vc.issuer"],
// ...

What if the $.vc field is a JWT encoded blob? Do we support de-encoding to operate? Are we ignoring any signatures? Do we support any other encodings? What're the rules around this?

When using the "rule": "pick", "count": 1 properties, there may be a use case for having count be a range, rather an integer.
Say you wanted to specify that one could supply up to X number of items from Group A. Or supply at least 1 but no more than 3 from Group B.

Something like minCount, maxCount could support this.

We need a concrete set of requirements for the language a verifier will use to describe selection criteria in a presentation definition.

These requirements may include:

• the ability to use nested boolean expressions
• selection of a number of items from a set.

are these required? what else is missing?

An input type that's likely to be very useful, especially as we boot up a world of users who have no existing credentials, is one that describes a raw data field requirement. An input of this type should include considerations for the following:

1. Specifying what the data value must be (string, number, boolean, etc.)
2. Specifying limitations on the value (min/max length, valid ranges, etc.)
3. Associating the entry with a field ID or name

Here is a strawman example of what such a data type might look like inside a Proof Definition:

{
  "type": "data",
  "field": "routing_number",
  "value": {
    "type": "string",
    "maxLength": 9
}

To address requirements 1 and 2 from the list above without reinventing the wheel, I propose that these things be specified via an existing standard: JSON Schema - https://json-schema.org/.

Please respond with your thoughts, and anything else you feel we should address in the scope of this input type.

I cannot find the JSON-LD context https://identity.foundation/presentation-exchange/submission/v1 included in the presentation_submission examples where "PresentationSubmission" must be defined.

Please add as comments links to existing proof requests and presentation definitions so we can get an idea of what folks have already done. This will help us to both try to make our presentation definition work with existing implementations and help us avoid redoing work that has already been done

as raised in #18

TODO: Presumably a request for input that has no constraints is allowed to be self-attested -- but sometimes this isn't good enough. How do I say, "As a university verifying your study habits, I explicitly DON'T want an attestation from your high school guidance counselor; I want you to tell me what you think about yourself?"

Orie correctly noted in our last call that we seem to be forcibly applying VC Data Model titles to our specs/objects, when in fact VCs are just one type of data that they may contain. As such, he suggested we avoid commingling those names with things that don't cleanly map to them, and instead pick ones that are more reflective of what this spec and objects do.

To that end, let's have a final namedown to get this thing squared away: I will post a few suggestions as separate comments here, and you can too, and everyone can help us settle this by favoriting the suggestions they prefer below. Try to favorite just one, but if you really can't decide between two, go ahead and favorite both.

On the C&C call on 2/12, it was suggested by @OR13, that the input selection logic could be modeled purely with JSON Schema. This issue tracks my progress on modeling this accordingly.

Add language for an optional session property which contains an object requiring at least a timestamp and hash of the entire Presentation Definition except for the hash using $existing_json_signing_standard. The object may include other fields such as a challenge/nonce, user ID, etc. to bind the response to a specific request. Presentation Definitions must have a present and comforming session property to be called Presentation Requests.

cc @OR13 and @dhh1188 who commented on #18 .

I feel that "session" is kind of an overloaded word. Any suggestions for a better field name? @csuwildcat @mikelodder7 @glcohen

The spec should have examples of requesting verified claims in each of the anticipated claims formats, including VCs and JWTs using eKYC-IDA verified claims syntax https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-requesting-verified-claims.

Recently, #19 was pushed with a correct spec.md but an index.html output that was not up to date. #20 fixed this, but really we should have some instructions in the README.md on what to ensure before pushing your changes to prevent this from happening again. Note that if you leave npm run edit going, then it'll make the changes but you have to remember to add the output file too.

as raised in #18

TODO: a demand for data should often be nonrepudiable and therefore must be signable by the Verifier. How do we do that?

Is there a specified way for the verifier to sign the presentation definition/request?

In reference to #24

We must support the specification of a proof of link secret constraint as expressed as a base64 encoded data field. The contents are not necessarily known ex-ante in their entirety or sometimes at all. Instead, implementation-specific algorithms must be ran to ensure their integrity and validity.

For the VC request is a restriction required (explicit or implicit) to ensure that requested attributes are sourced from the same credential. There is a relative context for attributes in a VC which may be important for some selection
For example challenge for the date, currency and value of a payslip. It is resonable that the verifier would require all three fields to be sourced from the same credential. An example where that may not be important is for contact details where a primary and secondary address may be sourced from different VCs.

There are some examples in the spec where schema.uri is a string.

various property values are specified as strings (such as the purpose property). Should we introduce support for localization of these property values?

As written today the presentation exchange draft is confusing to read - it is supposed to be a spec defining a data format, but there are transport details all over the place. The examples are hard to read if you are used to a different transport and it is difficult to understand where the line is between presentation exchange and all the rest.

If you were to create a generic name for the out-of-scope request/response that the presentation def/sub objects are embedded in, then you could remove the transport details from any examples that aren't explicitly intended to explain how a specific transport affects the objects.

I recommend the terms "information request" and "information response". Any of the transports already documented could fall under this term, and it works equally for authentication requests, authorization requests, attribute exchange requests or credential presentations. I have included an example high-level diagram which might help new readers understand where the defined objects are placed in relation to verifiers, holders, requests and responses before they dig into the data format itself.

"id": "citizenship_input_1",
      "group": ["C"],
      "schema": {
        "uri": "https://eu.com/claims/DriversLicense.json",
        "name": "EU Driver's License"
      },

can be

      "id": "citizenship_input_1",
      "group": ["C"],
      "schemas": [
      {
        "uri": "https://eu.com/claims/DriversLicense-v1.json",
        "name": "EU Driver's License"
      },
        {
        "uri": "https://eu.com/claims/DriversLicense-v2.json",
        "name": "EU Driver's License"
      }
      ]

from #18

DIDComm is lower level than the problem domain of this spec. It allows transmission of arbitrary content, so it is capable of carrying the data formats described here, in the same way you could transmit the format over TCP.

What's required in a DIDComm-based approach to communication is a higher-level protocol that explains the steps in the "dance" of proving something. This is the subject of Aries RFC 0037. That protocol, or future DIDComm based protocols like it, could be used to send a proof request (what is here called a "presentation definition") and receive a verifiable presentation (which could be wrapped in the presentation submission described here). The protocol is deliberately defined to be data format agnostic, so it is directly usable with this data format without modifying either doc.

TODO: I recommend that you draw a distinction between the definition of a presentation (here called a "presentation definition", very appropriately) and the request for such a presentation. It seems quite likely to me that presentation definitions will be standardized and published. For example, there might be a standard presentation definition that captures the requirements of people applying for citizenship in a given country. Once defined, the actual interactions where proofs are demanded need not define them again; they might just refer to them. Thus, it is possible to REQUEST a presentation without DEFINING it, by simply refering to a previously published DEFINITION. This is why the Aries protocol describes the challenge for proof as a "request", not a "definition" -- a request could include an inlined definition, or simply refer to one that's external to the request.

as said by @OR13:

We need concrete examples of the JSON representation of the messages required to support this spec over didcomm

this is related to #52

Add language talking about how to decode JWTs, Base64, etc. upon their encounter within the Presentation Submission. Is this normative or non-normative, and why?

        // TODO: how do we say that the prover must have a certain relationship to
        // the credential subject (e.g., BE the one and only subject, but
        // also things like "be the secondary account holder" or be the
        // father on the birth certificate?

re: https://github.com/decentralized-identity/presentation-exchange/pull/18/files#diff-9308a2575ae14de31b25f4459ecfc604R100

            // TODO: we need a way to do more than specify an allow list.
            // We must also support "accredited by issuer X" and also
            // "certified by a particular governance framework" (follow the
            // 'issue-edu' example in the Sample Data Structure section of

re: https://github.com/decentralized-identity/presentation-exchange/pull/18/files#diff-9308a2575ae14de31b25f4459ecfc604R107

TODO: add examples, cc @dhh1128

Perhaps this is out of scope for now because these checks can be done downstream by the business logic with data that are further provided. But it's certainly useful for a wallet to know additional constraints around a field, even if it must piece that data together from disparate systems.

from #18

       // TODO: we can't just list paths in VC JSON this way; we have
       // to link them to schemas ("if schema A, then path A.x;
       // if schema B, then path B.y"). Otherwise we create
       // possible paths that can be exploited to surprising effect.

As raised in #18

     // TODO: how do you express zero-knowledge predicate requirements?

The presentation request should be able to request predicates (and specify the values against which credential values should be tested)

as raised in #18

TODO: I recommend that you draw a distinction between the definition of a presentation (here called a "presentation definition", very appropriately) and the request for such a presentation. It seems quite likely to me that presentation definitions will be standardized and published. For example, there might be a standard presentation definition that captures the requirements of people applying for citizenship in a given country. Once defined, the actual interactions where proofs are demanded need not define them again; they might just refer to them. Thus, it is possible to REQUEST a presentation without DEFINING it, by simply refering to a previously published DEFINITION. This is why the Aries protocol describes the challenge for proof as a "request", not a "definition" -- a request could include an inlined definition, or simply refer to one that's external to the request.

The way that presentation exchange uses the term subject is misaligned with how both the verifiable credentials and the OpenID Connect world use the term.

My suggestion would be to use relative roles for this case -- selecter and presenter. This way, nobody gets confused about who is doing what, and we can layer presentation exchange as a flow overtop of any transport without collision of terms

as raised in #18

(TODO: unwind this advice to cease. A prover might have reasons to compute all the possible variations and pick the "best" one on the basis of which one is cheaper to present (has less fees associated), which one is more private, which credential they previously used with this verifier, etc. Stopping after the first match is not the business of the data format and is none of the verifier's business. Their requirements just way what is acceptable, not how it's computed.)

currently the algorithm for matching fields with input descriptors stops after the first match. Which field a prover wishes to select may be more nuanced than "pick the first one that matches"

Breaking requirements for a rules expression language, aka why we have our own (@csuwildcat):

• Picking between a set: "one of these two", "three of these five"
• Can reference. Looked at JSONLogic, etc. assume what they are selecting over is inside an object, not supporting a reference to an input group such as "ProofOfAddress"

Design criteria:

• Use cases using real JWTs/JSON-LDs/etc. must be reasonable
• Usability and understandability is a goal of Presentation Exchange, so humans should be able to make sense of these requirements

(@OR13, @wyc) what are rules expression languages and off-the-shelf tooling relevant to our criteria?

• JSON Logic
• MongoDB Querying

The spec does not appear to validate the VCs or eKYC-IDA JWTs received. If this is out of scope, please explicitly say so. And if so, please say when and where things like signature and issuer validation are expected to happen when this spec is used.

The industry will be best served to have a unified verified claims request spec that works at least for those represented in JSON, such W3C Verifiable Credentials and OpenID Connect for Identity Assurance JWTs. We should actively work on converging this specification with at least these others:

• eKYC-IDA claims request format https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html#name-requesting-verified-claims
• Edmund Jay's and Nat Sakimura's claims aggregation request spec https://bitbucket.org/edmund_jay/oidc-claims-aggregation/src/master/OpenID%20Connect%20Claims%20Aggregation.md

For extra credit, consider how to extend the verified claims request syntax to also support CBOR.

the variant of JSONPath called for in the spec: https://www.npmjs.com/package/jsonpath
Is this variant supported outside of node.js?

For the VC type the following may be good to have.

VC Input Request

• Attribute specification
• Optionality at the VC attribute level rather than the Input level to enable selective disclosure
• It is an implicit requirement all the attributes returned for a given issue and schema must be fore, correlation of

General Input Request

• Description (GDPR & UX Presentation)
• Reason (GDPR & Optional UX Presentation)
• Number of response elements e.g. 6 payslips for a bank loan. This is distinct from the existing pick selection.

Note on typing of VCs in the Workday solution
In the Workday Presentation requests, the credentials fields are typed by their Schemas, no further typing in the request is needed as he Verifier forms their query around their knowledge of the Schemas.
Side note JSON Schema is used to specify the Credential field types. See: https://w3c-ccg.github.io/vc-json-schemas/

From : https://github.com/decentralized-identity/presentation-request/blob/master/proposals/presentation-message-format.md input_selection & input_descriptors
{ "description": "6 Months of payslips", "issuers": { "dids": [ "did:work:EgLY8mysgbLmj542ygMKWo" ] }, "max": 6, "min": 6, "reason": "Payslips are used to determine credit worthiness", "schema": "did:work:KypRcDbLYAUwaA7nPuP3Tf;schema=1333;version=1.0", "properties": [{ "name": "currency", "required": true }, { "name": "grossPay", "required": true }, { "name": "payPeriodEnd", "required": true }, { "name": "payPeriodStart", "required": true } }

as raised in #18

TODO: A demand for proof should be able to include terms of service that the verifier commits to upon receipt of the data. We don't need to define that in great detail. I know that TOS was a rat hole in VC spec work. But we need to allow for it, or else the spec is unusable in many situations.

as raised in #18

TODO: eliminate "proofing". Identity proofing means something quite different from what we're talking about here. We should be using the word "proving".

It feels like leaving the verifier to wade through a schema definition or 'scheme-sniff' returned data for the crypto schemes the response items use would be messy, misfire-prone process. As such, should we consider adding a field to the Proof Presentation where the verifier can state what schemes they support verification of?

Place examples for definitions and submissions under this section for each target type.

So that developers can look at 1 section for how to handle a given target.

Provide tab examples under Submission, since we see credential representations there.

Nonces are great to use in protocols when brokering a new message exchange so that we can protect against attacks such as replay attacks.

If we were to include a nonce in the Presentation Definition, then it would allow Presentation Submissions to be tied to a specific "transaction" of Presentation Exchange, and this eliminates many classes of attacks.

However, if we were to require a nonce, then we will change the scope of Presentation Exchange in that it would no longer be a "static copy of a form" that anyone could use, but rather it would need to be coupled with a suitable PRNG to "stamp" each copy of the form with a nonce.

@dhh1128 is this an accurate portrayal of the issue? Thanks.

Ideas (not necessary mutex):

1. Require a nonce in the Presentation Definition
2. Make a nonce optional in the Presentation Definition
3. Allow for user-submitted nonces in the Presentation Submission, e.g., submit a "nonce" in the format of "{{pubkey}}-{{ISO-datetime}}", with the server checking that the "nonce" is within 30s of its current time.

re: https://github.com/decentralized-identity/presentation-exchange/pull/18/files/eba6f3f9b1ae7f27beaceea5c9a6bc66e5fc1980#diff-9308a2575ae14de31b25f4459ecfc604R53

In the case of VC responses, it looks to be assumed that the subject and holder are the same identity.
Is an explicit selector needed for this (or an explicit exception) e.g. You may hold a vaccination credential for a dog which is the subject of said credential. Or is it recommended that this be handled in business logic.

This must be the case or else any constraints against issuer will be meaningless or extremely misleading at best.

as raised in #18

(TODO: how do I match a field where the field must have a particular value for "@type" IN ADDITION to having a particular path? This is how I would require that a multi-subject cred have particular data for subject A, and different data for subject B, as with a birth certificate...)

Is it possible to modify the input evaluation algorithm to account for this?