It's the Final Namedown! (duh nuh nuh nuuuh, duh na-na-nuuuh)

[csuwildcat]

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.

[csuwildcat]

Conditional Exchange specification, with Condition Definition / Condition Submission objects.

[csuwildcat]

Prerequisite Exchange specification, with Requirement Definition / Requirement Submission objects.

[csuwildcat]

Qualifying Exchange specification, with Qualification Definition / Qualification Submission objects.

[csuwildcat]

Holdy-to-McVerifierface Prerequisite Validation Exchange specification, with Holdy-to-McVerifierface Prerequisite Definition / Holdy-to-McVerifierface Prerequisite Submission objects.

[OR13]

Prerequisite Exchange specification, with Requirement Definition / Requirement Submission objects.

feels closest to something generic enough to encompass HTML, VC / VP, JWS / JWE / JWT, and PII / Untrusted User Input.

[OR13]

Credential Manifest is for Issuers who are Verifiers before the Create Credentials.

Verifier Prerequisite Exchange spec is for Verifier who want a standard for requesting information from holder.

3 Objects: Manifest, Verifier Requirement Definition, Verifier Requirement Submission

[OR13]

Verifier Prerequisite Exchange specification, with Verifier Requirement Definition / Verifier Requirement Submission objects.

[csuwildcat]

Orie's entry into the Final Namedown! (above) is a more descriptive variant that uses a good term from the VC Data Model in the right way, so I urge folks to +1 it.

[swcurran]

I think regardless of the name, the answer would ideally be a verifiable presentation request. I'm not sure how far that has gone with W3C.

In the Hyperledger Indy world it's a concrete request from a verifier that defines what claims from what credentials the holder must provide. It needs some improvement - notably a way to express, required, optional and alternative claims to prove. But it does allow for listing the claims wanted, groups of claims (e.g. these must be from the same credential) and restrictions on the source of each claim/group of claims. Indy supports a presentation/presentation that crosses credentials, which may be hard where selective disclosure is not supported.

We built a demo quite a while ago that builds a decentralized flow by a holder asking an issuer service:

• "I want this credential",
• the issuer responds with a presentation request
• the holder looks in their credential store to see if they could provide a presentation.
• If not - recursively repeat the process with issuers of the missing credential to find the graph of credentials
• categorize the credentials they have, need and can get (they have the prerequisites) and need and can't yet get (missing prerequisites).
• get the credentials needed in the correct order.

I can share the demo if you are interested.

Bottom line from my message - if the verifiable presentation enables a sufficiently rich expression of requirements, it can be sufficient and can be used to automate a workflow.

[csuwildcat]

@swcurran I just talked with Orie about the same sort of thing, and the key understanding here is that these two data format objects are not specifically tied to VC presentations for credential issuance. These are generic requirement sets that could be fulfilled and never result in a credential at all. Also, the Verifier Requirement Definition can contain requirement input descriptors that are not VCs - there are many types of data/formats that you can include in a submission, as Orie noted: VCs, JWTs, raw JSON data (like a form submission), other typed data formats, etc.

[OR13]

calling something a presentation request, but allowing untrusted user input that is not a VC / VP seems like a bad idea to me... thats why its important to define the input data types and output data types, along with existing specifications before naming things... as I understand it, this spec could be used with arbitrary data and html, and have no VC or VP at all... and the spec would allow that.

[swcurran]

I don't get the "untusted user input" comment. If this discussion is not about verifiable credentials, then agree it should not be based on VC/VP terms.

[OR13]

I don't get the "untusted user input" comment. If this discussion is not about verifiable credentials, then agree it should not be based on VC/VP terms.

https://identity.foundation/proof-presentation/#proof-definition---all-features-exercised

{
  "input_selection": [
    {
      "rule": "all",
      "from": ["A"]
    },
    {
      "rule": "pick",
      "count": 1,
      "from": ["B"]
    }
  ],
  "input_descriptors": [
    {
      "type": "data",
      "group": ["A"],
      "field": "routing_number",
      "value": {
          "type": "string",
          "maxLength": 9
      }
    },
    {
      "type": "data",
      "group": ["A"],
      "field": "account_number",
      "value": {
        "type": "integer",
        "maxLength": 17,
        "required": true
      }
    },
    {
      "type": "idtoken",
      "group": ["A"],
      "redirect": "https://acmebank.com/oauth",
      "parameters": {
        "client_id": "dhfiuhsdre",
        "scope": "openid+profile"
      }
    },
    {
      "type": "vc",
      "group": ["B"],
      "schema": "https://eu.com/claims/IDCard",
      "constraints": {
        "issuers": ["did:foo:gov1", "did:bar:gov2"]
      }
    },
    {
      "type": "vc",
      "group": ["B"],
      "schema": "hub://did:foo:123/Collections/schema.us.gov/Passport",
      "constraints": {
        "issuers": ["did:foo:gov1", "did:bar:gov2"]
      }  
    }
  ]
}

Note that the current example contains many things which are not VC / VP / JWT.

[swcurran]

Ah...got it. We are assuming a trusted communication channel.

[csuwildcat]

@swcurran think of these two objects this way:

Verifier/processor of things: "Setting aside any activity/goal we may be engaged in - which could be anything - provide me with a selection of the following odds and ends, which may include VCs, raw data, JWTs, etc."

Entity who has said things: "Sure, here are some things from those groups of things you said I needed to submit to you"

What the things are they are requiring/submitting is not bound to VCs specifically, or the issuance of a credential, it's just a list of stuff someone is demanding to proceed with some activity, which could be anything.

[swcurran]

Yes - agreed it can go beyond VCs. We have discussed the need to express non-VCs ways to do it. Makes it hard to do an API so we were assuming the VP might be extended vs something different.

On Wed, Feb 12, 2020 at 12:14 PM Daniel Buchner notifications@github.com wrote:

@swcurran https://github.com/swcurran think of these two objects this way:

Verifier/processor of things: "Setting aside any activity/goal we may be engaged in - which could be anything - provide me with a selection of the following odds and ends, which may include VCs, raw data, JWTs, etc."

Entity who has said things: "Sure, here are some things from those groups of things you said I needed to submit to you"

What the things are they are requiring/submitting is not bound to VCs specifically, or the issuance of a credential, it's just a list of stuff someone is demanding to proceed with some activity, which could be anything.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/proof-presentation/issues/10?email_source=notifications&email_token=AAHYRQT2IXQ76Y2TN34GKVLRCRKCFA5CNFSM4KT6DA72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELSHD5A#issuecomment-585396724, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHYRQWKYZGU3G4OKNTNKVLRCRKCFANCNFSM4KT6DA7Q .

--

Stephen Curran Principal, Cloud Compass Computing, Inc. (C3I) Technical Governance Board Member - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: *https://calendly.com/swcurran https://calendly.com/swcurran

[dlongley]

Whatever is done here, it would ideally be compatible with CHAPI (The Credential Handler API). CHAPI essentially supports arbitrary JSON and therefore the transport of just about any sort of data (whether it be VP/VC data or something else). Of course, if it can be represented in JSON it should be fairly easy to be compatible, but it would be good to take into consideration some of this other (not yet settled, but used in existing software) work:

https://gist.github.com/dlongley/74cb42563eb4a983166f6f5fb58282d8

Note that a "Verifiable Presentation" doesn't have to include VCs; it is intended to be a way to present all kinds of things (despite VCs being the only thing in a W3C REC so far) in a way that can have an authentication proof attached to it. We present Authorization Capabilities (zcaps) via a VP, for example.

[csuwildcat]

@dlongley the intention is definitely for this to be JSON, if that's the key bit you're noting for use with CHAPI. The input typing and option selection rules are what differentiate this, so I would like to ensure that we preserve the intent to support those needs, regardless of the final data format prop/value composition.

[OR13]

I guess I was wrong to assume that a "Verifiable Presentation" always contained ONLY VCs... AFAIK CHAPI would be a transport, which this work could support, similar to the universal verifier APIs.

[OR13]

Presentation Exchange specification with Presentation Definition / Presentation Submission objects.

Transport Agnostic with support for HTTP / CHAPI / DIDComm?

[csuwildcat]

Yep, what Orie said. Should be able to slap this into OIDC, CHAPI, DID Comms, etc., given this is just the payload guts that help people articulate needs and make choices using the selection optionality they are provided with.

[csuwildcat]

Presentation Exchange specification with Presentation Definition / Presentation Submission objects.

Transport Agnostic with support for HTTP / CHAPI / DIDComm?

Two questions:

1. What are you intending by posting this riff on the names? Are you saying those should be the names?
2. What was your question about transport agnostic, I didn't understand. My statement was rather simple: these JSON objects don't care whether they are being sent over HTTP, in DID Comm envelopes, over Bluetooth, etc., or which particular cred negotiation scheme (Aries, OIDC Self-Issued, or other) integrates them.

[OR13]

1. What are you intending by posting this riff on the names? Are you saying those should be the names?

Yes, its a proposal for the names

2. What was your question about transport agnostic, I didn't understand. My statement was rather simple: these JSON objects don't care whether they are being sent over HTTP, in DID Comm envelopes, over Bluetooth, etc., or which particular cred negotiation scheme (Aries, OIDC Self-Issued, or other) integrates them.

My point was to make it clear that these names don't imply a Transport.

[csuwildcat]

@OR13 I'm fine with the names you just proposed. Let's see what other folks think!

[swcurran]

I'm fine with the names. I'd also go with "Presentation Request" and "Presentation" as the more general forms of the "Verifiable Presentation Request" and "Verifiable Presentation" (if we assume those latter terms can only reference verifiable credentials/claims.

Agree that this is a data format that is transport agnostic. Ultimately, the submission gets turned into a query for stuff you have that will satisfy (some or all of) the request, and in turn, the query results become the response.

[brentzundel]

I'm also fine with Orie's latest naming recommendations.

[csuwildcat]

I'm fine with the names. I'd also go with "Presentation Request" and "Presentation" as the more general forms of the "Verifiable Presentation Request" and "Verifiable Presentation" (if we assume those latter terms can only reference verifiable credentials/claims.

I would like to refrain from using the term Request, because it invokes the idea that the thing we're working on is related to the actual sending of the packets/data over a channel, like an HTTP request/response. The word Exchange avoids commingling those other concepts with what this body of work defines, so that's why I am advocating for it.

[brentzundel]

So, are we back to presentation definition?

On Fri, Feb 14, 2020, 10:04 Daniel Buchner notifications@github.com wrote:

I'm fine with the names. I'd also go with "Presentation Request" and "Presentation" as the more general forms of the "Verifiable Presentation Request" and "Verifiable Presentation" (if we assume those latter terms can only reference verifiable credentials/claims.

I would like to refrain from using the term Request, because it invokes the idea that the thing we're working on is related to the actual sending of the packets/data over a channel, like an HTTP request/response. The word Exchange avoids commingling those other concepts with what this body of work defines, so that's why I am advocating for it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/decentralized-identity/proof-presentation/issues/10?email_source=notifications&email_token=ACPFKP2YNGX5V3VLWM5NBOTRC3FKZA5CNFSM4KT6DA72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELZWYCQ#issuecomment-586378250, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPFKP6W2FRMAPSEYAQTWILRC3FKZANCNFSM4KT6DA7Q .

[csuwildcat]

Hey folks, it sounds like we have some consensus on the following designations: Presentation Exchange specification with Presentation Definition / Presentation Submission objects.

Can you please all +1 this comment or post any explicit disagreements so we can close this out?

[csuwildcat]

Barring any last minute, extremely persuasive arguments, I am inclined to close this out using the Presentation Exchange specification with Presentation Definition / Presentation Submission names going forward. I will be on the call today with Brent to finalize a few of these Issues.

[csuwildcat]

I started with some string changes to the strawman spec to reflect this consensus, and will close this out with these being the new names going forward.