decentralized-identity / credential-manifest Goto Github PK

Styling for issuers could be noisy/duplicated. Consider pushing it to the issuer's site under a well-known did config.
If the styling for the issuer is optional this is not a problem.

The Credential Manifest isn't really a manifest, and literally every human on earth who ever hears the term is thrown into a state of almost permanent confusion, thus I think we should rename it. Given This resource/JSON doc describes the necessary inputs to be considered by an issuer for issuance of a credential, it is more like a Credential Application Form. I would be fine calling it that, given it is very self-descriptive, but it does sound rather lame. Let the bikeshedding begin.

Re-PR the typos fixed in #68 PR (rest of PR superceded on today's call)

About the path property, the spec currently reads:

The object MAY contain a path property, and if present, its value MUST be a JSONPath string expression.

But the examples have arrays of JSONPaths

      {
        "path": ["$.donor", "$.vc.donor"],
        "label": "Organ Donor"
      }

Are these meant to be fallbacks of some sort, tried in order?

The W3C WG has agreed that the resulting credential (without a proof) should be identical regardless of which proof is added to it to create a verifiable credential and then verified and removed to return the credential.
Consequently the manifest should use the path parameter to refer to the properties of the credential and not to the properties of the (different flavours of) verifiable credential e.g. you do not need different paths to refer to the subject id of a credential as it is identical regardless of how the credential is eventually turned into a verifiable credential by the issuer, even if the way the subject id is encoded in the verifiable credential is different for the different proof formats

presentation definition and wallet rendering spec references should be to published versions, not just latest

It specifies that for an issuer, styles is a required property: https://identity.foundation/credential-manifest/#credential-manifest-3
However, the spec notes that the property is optional.

The spec should be clear that id fields must be unique within a certain context, not necessarily globally

There's a use case to display information about the Claim before it's issued and transferred to the Holder. If an issuer only uses path within the Output Descriptor Object (ODO) then there would be nothing to display to the user.

Ideas:

• Have a separate property that behaves similarly to the existing "display" property but only allows text + label
  • IMO this would give the most flexibility
• Add an example property to the ODO that could be either an inline JSON or URI that resolves to a JSON. This example JSON would act as the target for the path values within the ODO

when the user presents credentials (assuming VCs) in presentation_submission, based on the presentation_definition in the credential_manifest, they need to be replay protected, so that I am not replaying complete VCs that belong to someone else.

To do that it makes sense to have a flow like 1/ holder tells which credential it wants issued; 2/ issuer gives the wallet a challenge (server provided nonce for example); 3/ holder presents input VCs in presentation_submission bound to that challenge.

I think that would mean decoupling presentation_submission and credential_application.

Aries seems to be taking a similar approach: https://github.com/hyperledger/aries-rfcs/blob/main/features/0511-dif-cred-manifest-attach/README.md#propose-credential-attachment-format

they need an id field at the top level.

Consider adding a github action to generate html from md

Need new name for "credential submission". Ideas thrown out:

• Credential manifest request
• Credential supplication
• credential acceptance
• credential solicitation

I am concerned about the security implications of having a credential manifest include display instructions. The format includes no way of verifying that the display instructions correspond to exactly and only the data that a credential contains; therefore, a malicious issuer could construct an innocent-looking display but have a credential with content that does not match it. An exaggerated example of how this could be exploited is that an employer could construct a letter of recommendation for Alice, and could have the display show a blue ribbon and 5 stars -- but could have a field in the credential that says to the verifier "Actually, Alice is a terrible employee. Don't hire her." Alice would not realize the true content of the credential because the display instructions that format for human consumption are quite different from the true content.

This is an exaggerated example, but the general principle here is that display of a credential and content of a credential should be provably associated with one another; if they are not, the display becomes a vector for confusion, ambiguity, or manipulation.

I recommend removing the display attribute entirely, and instead coming up with a standard algorithm that renders credential fields in a predictable way.

I think we need to know the expected type of the value returned when evaluating the JSONPaths in the display property. In languages like java/swift (native mobile apps) it's harder to be as dynamic as what JS lets us do.

In addition to path I'd suggest something that contains JSON schema so that it can be parsed first in order to know how the value at the path should be handled.

So currently the "display" property is used before and after the holder has a credential. I think this should be split apart to two separate properties, for before and after the holder recieves a credential.

{
  "output_descriptors": [
    {
      // ...
      "offer_display": {
        "title": {
          "text": "Washington State Driver License"
        },
        "subtitle": {
          "text": "Class A, Commercial"
        },
        "description": {
          "text": "License to operate a vehicle with a gross combined weight rating (GCWR) of 26,001 or more pounds, as long as the GVWR of the vehicle(s) being towed is over 10,000 pounds."
        },
        "properties": [
          {
            "label": "Organ Donor",
            "text": "True/False"
          }
        ]
      },
      "display": {
        "title": {
          "path": ["$.name", "$.vc.name"],
        },
        "subtitle": {
          "path": ["$.class", "$.vc.class"],
        },
        "properties": [
          {
            "path": ["$.donor", "$.vc.donor"],
            "label": "Organ Donor"
          }
        ]
      }
    }
  ]
}

This "offer_display" (I don't like this name, open to others!) would be used to show the holder info about the credential before they submit the "presentation_submission" and would hold static "text" fields. And then the "display" property is strictly drived from the credential (using "path" to find the field to display from the credential).

There was also some talk on whether the current "display" object should be embedded into the issued credential. If we want to do that then I'd suggest keeping "offer_display" (just "text" and "label" + "text") on the Output Descriptor but keep the name "display".

{
  "output_descriptors": [
    {
      // ...
      "display": {
        "title": {
          "text": "Washington State Driver License"
        },
        "subtitle": {
          "text": "Class A, Commercial"
        },
        "description": {
          "text": "License to operate a vehicle with a gross combined weight rating (GCWR) of 26,001 or more pounds, as long as the GVWR of the vehicle(s) being towed is over 10,000 pounds."
        },
        "properties": [
          {
            "label": "Organ Donor",
            "text": "True/False"
          }
        ]
      },
    }
  ]
}

{
  "type": ["VerifiableCredential", "..."],
  "display": {
    "title": {
      "path": ["$.name", "$.vc.name"],
    },
    "subtitle": {
      "path": ["$.class", "$.vc.class"],
    },
    "properties": [
      {
        "path": ["$.donor", "$.vc.donor"],
        "label": "Organ Donor"
      }
    ]
  }
  // ...
}

We discussed on a call the idea to put input_selection and input_descriptors into an independent object, and seemed to have agreement.
In the Aries community we have been using the term Presentation Definition to describe the holder traits requested by a verifier. I would love for these notions to be aligned and recommend that we call the independent object that contains input_selection and input_descriptors to be called a Presentation Definition
More information on presentation definitions

We need a better way to discover Credential Manifests, let's make that happen.

After decentralized-identity/presentation-exchange#339 update schema references to absolute URL paths / do not redefine them in this spec

This is different from #7, which is about protocols.

The credential manifest should identify the Issuer's supported output formats for credentials (JWTs, JSONLD, CWTs, etc.)

Display Mapping Objects that use "path" should also have a "schema" property to indicate the type of the value at the resolved "path". This "schema" property would be a subsect of JSON schema, it would just have a "type" field and if "type" is "string" then there is an optional "format" field.

"display": {
  "title": {
    "path": ["$.name", "$.vc.name"],
    "schema": {
      "type": "string"
    }
  },
  "subtitle": {
    "path": ["$.class", "$.vc.class"],
    "schema": {
      "type": "string"
    }
  },
  "properties": [
    {
      "path": ["$.donor", "$.vc.donor"],
      "label": "Organ Donor",
      "schema": {
        "type": "boolean"
      }
    },
    {
      "path": ["$.expirationDate", "$.vc.expirationDate"],
      "label": "Expiration Date",
      "schema": {
        "type": "string",
        "format": "date",
      }
    }
  ]
}

I'm thinking we'd want to limit "type" to: "string" | "boolean" | "number" | "integer", but there may be times when people would want to use "array" but that complicates a lot (array of what? array of string and numbers?).

And then "format" would be limited to: "date-time" | "time" | "date" | "email" | "idn-email" | "hostname" | "idn-hostname" | "ipv4" | "ipv6" | "uri" | "uri-reference" | "iri" | "iri-reference", the wallet could then know if it should format the text in a specific way. I think "date-time", "time", and "date" would be the ones most wallets do anything with, turning an ISO date string into DD-MM-YYY, some of the others could render a clickable link tho. The actual rendered format would still be up to the wallet, this just tells the wallet the format the data is in so it can correctly display it.

https://github.com/rjsf-team/react-jsonschema-form

styles and display should be combined.

Credential Manifests need identifiers that:

1. Distinguish one version from another
2. Are valid URIs

Here's an example of one vendor's variant of a Credential Manifest-like object that describes the sorts of things we would want in a Credential Manifest:

{
  "id": "ContosoUniversityCard",
  "display": {
    "id": "display",
    "locale": "en-US",
    "contract": "https://example.com/dev-v1.0/dfsdfadfa-sdfadsa-45f2-be2d-61e352b51eef/portableIdentities/contracts/ContosoUniversityCard",
    "card": {
      "title": "University Graduate",
      "issuedBy": "Contoso University",
      "backgroundColor": "#821618",
      "textColor": "#F8F8FF",
      "logo": {
        "uri": "https://test-relyingparty.azurewebsites.net/images/university_logo.png",
        "description": "Contoso University Card."
      },
      "description": "Contoso University card for alumni."
    },
    "consent": {
      "title": "Do you want to get your Contoso Graduate Card?",
      "instructions": "You will need to sign in with your Contoso University Credentials."
    },
    "claims": {
      "vc.credentialSubject.graduationYear": {
        "type": "String",
        "label": "Status"
      },
      "vc.credentialSubject.name": {
        "type": "String",
        "label": "Name"
      },
      "vc.credentialSubject.mascot": {
        "type": "String",
        "label": "Mascot"
      },
      "vc.credentialSubject.gpa": {
        "type": "String",
        "label": "GPA"
      },
      "vc.credentialSubject.major": {
        "type": "String",
        "label": "GPA"
      }
    }
  },
  "input": {
    "id": "input",
    "credentialIssuer": "https://example.com/dev-v1.0/sdfasdfa-sdfasda-45f2-be2d-61e352b51eef/portableIdentities/card/issue",
    "issuer": "did:ion:EiCfeOciEjwupwRQsJC3wMZzz3_M3XIo6bhy7aJkCG6CAQ?-ion-initial-state=eyJkZWx0YV9oYXNoIjoiRWlEMDQwY2lQakUxR0xqLXEyWmRyLVJaXzVlcU8yNFlDMFI5bTlEd2ZHMkdGQSIsInJlY292ZXJ5X2NvbW1pdG1lbnQiOiJFaUMyRmQ5UE90emFNcUtMaDNRTFp0Wk43V0RDRHJjdkN4eTNvdlNERDhKRGVRIn0.eyJ1cGRhdGVfY29tbWl0bWVudCI6IkVpQ2gtaTFDMW1fM2N4SGJNM3pXemRRdExxMnBvRldaX25FVEJTb0NhT2JZTWciLCJwYXRjaGVzIjpbeyJhY3Rpb24iOiJyZXBsYWNlIiwiZG9jdW1lbnQiOnsicHVibGljX2tleXMiOlt7ImlkIjoic2lnXzBmOTdlZWZjIiwidHlwZSI6IkVjZHNhU2VjcDI1NmsxVmVyaWZpY2F0aW9uS2V5MjAxOSIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6InNlY3AyNTZrMSIsIngiOiJoQ0xsb3JJbGx2M2FWSkRiYkNxM0VHbzU2bWV6Q3RLWkZGcUtvS3RVc3BzIiwieSI6Imh1VG5iTEc3MWU0NDNEeVJkeU5DX3dfc3paR0hVYUcxUHdsMHpXb0h2LUEifSwicHVycG9zZSI6WyJhdXRoIiwiZ2VuZXJhbCJdfV19fV19",
    "attestations": {
      "idTokens": [
        {
          "encrypted": false,
          "claims": [
            {
              "claim": "extension_Graduation_Year",
              "required": false,
              "indexed": false
            },
            {
              "claim": "extension_GPA",
              "required": false,
              "indexed": false
            },
            {
              "claim": "extension_Major",
              "required": false,
              "indexed": false
            },
            {
              "claim": "name",
              "required": false,
              "indexed": false
            }
          ],
          "required": false,
          "configuration": "https://example.com/.well-known/openid-configuration",
          "client_id": "ve65e76be75e-6e6be5-49c1-97ab-410abaa750ac",
          "redirect_uri": "portableIdentity://verify"
        }
      ]
    }
  }
}

In the Terminology section of the wallet-rendering spec, it says

Labeled Display Mapping Object
ref:Labeled Display Mapping Objects extend from Display Mapping Objects. See Labeled Display Mapping Object

Labeled Display Mapping Object points to a section that doesn't seem to exist.

Hi!

In Section 4.2.1 it says that

The Output Descriptor Object MAY contain a display property, and its value MUST be an object composed as defined in the DIF Data Display specification.

According to the linked Wallet Rendering spec, it looks like when you're using a path, an object must contain a schema property. I noticed the examples here in Credential Manifest don't have it. I'm wondering if the omission is intentional or not.

(If it's not intentional, I could make a PR to add it in to the examples)

Note to self: sometimes we mix decoded forms of credentials and it's unclear to implementors. Ensure we clean up

Hi everyone,

There's something I'm finding confusing in the Credential Application section.

It says:

The Credential Application object MUST contain a credential_application property.

and...

The Credential Application object MUST contain a presentation_submission property IF the related Credential Manifest contains a presentation_definition.

... and here's the example from the spec:

{
  "credential_application": {
    "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
    "manifest_id": "WA-DL-CLASS-A",
    "format": {
      "ldp_vc": {
        "proof_type": [
          "JsonWebSignature2020",
          "EcdsaSecp256k1Signature2019"
        ]
      }
    }
  },
  "presentation_submission": {
    "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
    "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "descriptor_map": [
      {
        "id": "input_1",
        "format": "jwt_vc",
        "path": "$.verifiableCredential[0]"
      },
      {
        "id": "input_2",
        "format": "ldp_vc",
        "path": "$.verifiableCredential[1]"
      },
      {
        "id": "input_3",
        "format": "ldp_vc",
        "path": "$.verifiableCredential[2]"
      }
    ]
  }
}

It sounds like a Credential Application contains a credential_application and (optionally) also a presentation_submission.

Does this mean that a Credential Application object, when embedded in another object, would look like this, with effectively a nested "credential_application" layer?

{
  "credential_application": {
    "credential_application": {
      "id": "9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
      "manifest_id": "WA-DL-CLASS-A",
      "format": {
        "ldp_vc": {
          "proof_type": [
            "JsonWebSignature2020",
            "EcdsaSecp256k1Signature2019"
          ]
        }
      }
    },
    "presentation_submission": {
      "id": "a30e3b91-fb77-4d22-95fa-871689c322e2",
      "definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
      "descriptor_map": [
        {
          "id": "input_1",
          "format": "jwt_vc",
          "path": "$.verifiableCredential[0]"
        },
        {
          "id": "input_2",
          "format": "ldp_vc",
          "path": "$.verifiableCredential[1]"
        },
        {
          "id": "input_3",
          "format": "ldp_vc",
          "path": "$.verifiableCredential[2]"
        }
      ]
    }
  }
}

I noticed that the examples for the Credential Manifest and Credential Fulfillment objects have that extra outer layer, I guess because they also specify how they're supposed to be embedded in a parent object, however Credential Application doesn't specify this. I just assumed it should be credential_application... but that creates a weird sort of duplicate nesting, so I'm not exactly sure what's intended.

Thanks!

In the same way we have issuer styles for rendering acquisition UI, we need a property that describes the styles for rendering the output credential, including the values that are present in the UI, taken from the credential.

It could be a hashlink, ipfs lint, https url, or did uri...it should not be a flat sha256 hash...

Holder visits issuer.com
Holder browses credential manifests
Holder requests a credential via PE definition in one such manifest
Holder receives PE + domain and challenge for issuer.com
Hodler submits PE VP to issuer.com

Allowing the prospective issuer of a credential to assert their properties (e.g., thumbnail, description) without any proof feels to me like an antipattern and an invitation to phishing. It is highly insecure, and it reinforces a faulty assumption that it's okay to have individuals and institutions play by different rules as far as authentication is concerned.

I would be happier if we removed the self-asserted properties of the issuer and instead relied upon verifiable credentials to establish the properties of the would-be issuer. If this is a deal-breaker because some people who want to use credential manifests are committed to this insecure behavior, an alternative might be to explain why the self-asserted properties are dangerous and caution people not to use them.

Much like how in PE there is a top-level "format" field that communicates the types of VCs/VPs the verifier can process, CM needs to communicate to the holder the types of VCs/VPs that will be returned.

CM shoulds use the same schema used by PE's format in CM's format, and CM should have this be a top-level field.

The idea of presentation_definition as a field is to allow an issuer to say, "We'll issue this credential to you if you prove the thing described in presentation_definition. The concern I have with this is that it's a weak and flawed substitute for a real proving protocol -- and by having a field for it in the credential manifest, we may encourage harmful shortcuts.

If the potential issuer wants to condition issuance on proof, there's a robust and easy way to do that: ask the potential holder for proof before issuing, in a separate interaction. Doing so will involve some kind of proving protocol (my natural inclination would be to use DIDComm, but CHAPI could also could be used, as could OIDC+SIOP). All of these describe interaction patterns that include properties such as:

• The ability to negotiate how much is proved, how it is proved, and in what order
• The ability to communicate errors that distinguish between communication problems, crypto problems, versioning problems, and the unacceptability of the furnished proof
• The ability to take turns incrementally accumulating proof/trust (possibly large and rich bodies of proof) until both parties are satisfied

Using a protocol that provides these features is the optimal way to build robust "prove this before we issue to you" guarantees into a workflow. As far as I can tell, the presentation_definition field does not contain a challenge or nonce, though I may have missed something. If I am correct, then the data supplied as a response to the credential manifest is subject to replay attacks. Even without that vulnerability, it is hampered from being a robust solution due to the bulleted issues I listed above.

I believe the argument in favor of including this field is that it allows a single round trip to express the entire interaction. However, I believe this is not as desirable as it sounds at first glance, because A) the standards of proof that an issuer will have will very often require a pre-existing relationship that is meaningful and long-running; and B) often payment will be involved. Payment is already a separate protocol. Therefore, trying to lump everything into one protocol is already a non-goal.

I would be happier if presentation_definition were removed from the format. Failing that, I think we at least need a section of the spec that discusses what its risks are, and how the problem could be solved more robustly.

• Microsoft
• Google
• Amazon
• Apple

A Credential Manifest supports multiple credentials being issued to a holder. But that holder needs to know which Output Descriptor Object corresponds to which issued credential. I have one idea for this, but this is meant to be a discussion of other ideas (if we come up with a better idea it might be worthwhile to see if it can be brought over to PE).

Idea:

Add an id to the Output Descriptor Object

Similar to the Input Descriptor Object from PE an id can be added to the Output Descriptor Object. And then when the issuer hands back claims to the holder they would also include a "offer_fufillment" (open to different names) that is similar to the "presentation_submission" from PE and would describe which claim is for which Output Descriptor.

Spec examples should all be compliant with the spec.
For example, the first example contains a version property which is not mentioned in the spec.

Additionally there is no JSON Schema for the Credential Manifest object to validate this data.

Is this property to be used before or after the credential has been claimed by the user?

I was thinking it would be used to show the user info about the credential they are being offered before they claim it. But if it's used for that case I wasn't sure what the path field would be applied against.

Do we want to include a property the issuer can use to indicate what credential issuance protocols it supports?

minor typo of CALIM instead of CLAIM at https://github.com/decentralized-identity/credential-manifest/blob/1fc76252922a53efa9ebacdaccfc4cb639aa2781/spec/spec.md#general-composition

There is a requirement for a protocol that can support credential issuance both 1/ starting with the credential_manifest discovery and 2/ without such discovery, where the holder simply tells the issuer in the request which credential type the holder is requesting. The use-case for latter would be when the issuer already has all the information needed to issue a credential to that user for example - we would want to prevent the user from presenting the credentials that the user does not want.

In the request of each flow, in 1/ holder would pass credential manifest id in the credential_application, while in 2/ holder would pass the credential type directly. This leads to two separate syntaxes. Would it be possible to have an option in credential manifest to pass requested credential both by reference (manifest_id) and by value (credential type)?

Aries seems to be taking a similar approach, choosing to pass credential_manifest with credential type/schema directly instead of credential_applicaiton with manifest_id: https://github.com/hyperledger/aries-rfcs/blob/main/features/0511-dif-cred-manifest-attach/README.md#propose-credential-attachment-format

Apologies if this has been discussed or if this is already possible in the current spec.

We would like to add a custom human friendly claim display name.

Example:
ISS to Issuer
DOB to Date of Birth

I want to propose a new structure to Credential Manifest (and also change the spec name to Credentail Exchange). I feel by breaking down the components into their own standalone data blobs we can help cover more use cases.

This proposition helps with the following use cases:

• Credential Display
• Credential Issuance
• Source of Display Information
  • While not directly discussed, if components are broken down like this each component could be signed independently. Then the whole credential_exchange could be signed as well, but it would probably make more sense for the signing of the CE to be done at the envelope level, like the PE

Manifest Styling

Purpose:

• Styling manifests

{
  thumbnail: {
    uri: '',
    alt: ''
  },
  hero: {
    uri: '',
    alt: ''
  },
  background: {
    color: '',
  },
  text: {
    color: '',
  },
}

Issuer Manifest

Purpose:

• Display info about an issuer
• Styles for the manifest

Notes:

• Should this have a Issuer Display part to mirror Credential Manifest below?

{
  id: 'did:...',
  name: 'Washington State Government',
  styles: {
    // Manifest styling
  },
}

OR

{
  display: {
    title: {
      text: 'Washington State Government'
    },
    subtitle: {
      text: 'did:...'
    }
  },
  styles: {
    // Manifest styling
  },
}

Credential Offer Display

Purpose:

• Has details about what to display about the VC
  • "This is the type of credential and here's some info about it"

Notes:

• 99% of the time is provided by the issuer
  • It's for showcasing the VCs that the issuer is offering

{
  title: {
    text: ''
  },
  subtitle: {
    text: ''
  },
  description: {
    text: ''
  },
  properties: [
    {
      label: '',
      text: '',
    }
  ],
}

Credential Display

Purpose:

• Has details about what to display from a VC

Notes:

• Can either be provided by the issuer or a third party.
  • The issuer could even point to a 3rd party location
  • Or some sort of registry could be made where users can select different displays
• I'm not sure if this should restrict displayed values to just values that are pulled from the VC
  • I do feel like being able to display as if it were apart of the VC but not really there could be seen as dangerous/a dark pattern

{
  title: {
    path: ['']
  },
  subtitle: {
    path: ['']
  },
  description: {
    path: ['']
  },
  properties: [
    {
      label: '',
      path: ['']
    }
  ],
}

Credential Manifest

Purpose

• Combines offer display, display, and styling for credential

{
  display: {
    // Credential Display
  },
  offer_display: {
    // Credentail Offer Display
  },
  styles: {
    // Manifest Styles
  }
}

Credential Exchange

Purpose:

• Combines issuer manifest, credential manifest(s), and presentation definition
• Has support for multiple credential manifests

Notes:

• This is essentially what Credential Manifest is today

{
  issuer: {
    // Issuer Manifest
  },
  credentials: [
    {
      // Credential Manifest
    }
  ],
  presentation_definition: {
    // Presentation Definition
  }
}

In order to ensure the credential name property (which specifies the credential that will be output in response to submission of the CM) is not used to alias an entry in a singular credential type registry, we may want to force that field to be a URI related/ to the issuer's DID

In order to have replay protection in PE, but less messages over all.... it would be helpful to allow an issuer to provide replay protection when they hand out CMs over transports like DIDCom and CHAPI.... this obviously does't work for for static website / hubs... but for interactive transports... it saves an message... because the holder doesn't need to go ask for a domain and challenge before proceeding.

If a Credential Manifest contains dependent Claims or Credentials that need to be provided, there needs to be a way for the Subject to discover Issuers that can issue that dependent Claim in order to proceed with the acquisition of the original credential.

1. As an issuer I want to provide a list of credential that I support for the purpose of holder discovery
2. As a wallet implementer, I want to know how to display a credential to the user
3. As a wallet implementer, I want to know that the display information from an issuer is being used.
4. As a wallet implementer, I want to know that the display information for a credential comes from a 3rd party (EFF, etc.)

There is currently no way to discover claims manifests. Furthermore, it is not specified how to submit the required information from the claim manifest to the issuer. What happens if the claims manifest refers to a verified credential available on a different hub or issuer service. Should we specify that the response is a claims manifest as well?

@csuwildcat are these going to be separate specs?