# Credential Manifests
As we've been researching credential templates, I keep coming back to the credential manifest specification. There has been slow, continuous work on the specification, and I think it'll fulfill our needs for credential templates.

## Why Credential Manifests
- Has community support. This is a long standing spec
- Fits nicely with the presentation exchange spec: https://identity.foundation/presentation-exchange/#terminology
- Describes the required fields of a credential so that holders and verifiers know what attributes each issuer is available to issue. Is extensible with custom fields if needed
- Communicates the styling and display properties of credentials
- Transport Agnostic

## Goal
Create an open source library implementation of credential manifests.
Host credential manifests as a microservice in our API.

Must do three things:
- Describe **the attributes and the attribute types**.

## Data Model

{
  "credential_manifest": {
    "issuer": {
      "id": "did:key:123456",
      "name": "Vaccination Clinic",
      "styles": {  // probably for future impl
        "thumbnail": {
          "uri": "https://dol.wa.com/logo.png",
          "alt": "Washington State Seal"
        },
        "background": {
          "color": "#ff0000"
        },
        "text": {
          "color": "#d4d400"
        }
      }
    },
    "output_descriptors": [
      "schema": [
        {
          "uri": "https://schema.trinsic.id/123456#vaccination-card"
        }
      ],
      "display": {
        "title": {
          "$.name",
          "$.vc.name"
        }
      }
    ],
    "format": { // describes the formats the issuer can issue in
      "ldp_vc": {
        "proof_type": [
          "JsonWebSignature2020",
          "Ed25519Signature2018",
          "EcdsaSecp256k1Signature2019",
          "RsaSignature2018"
        ]
      },
      "ldp_vp": {
        "proof_type": ["Ed25519Signature2018"]
      },
      "ldp": {
        "proof_type": ["RsaSignature2018"]
      }
    },
    "presentation_definition": {}
  }
}

Contexts have a type. Can't have it as an attribute name.

For now, just generate

## Create Manifest
As a provider, when I create a manifest I must provide a valid json schema to specify the attributes. I'll likely use some UI tool to construct my json schema. Once I have the json object, I'll then decide on some display options. Specifically, which attribute is specified as the title, subtitle, and description, if any.

example:

req: {
  "schema": {
    "$schema": "http://json-schema.org/draft-07/schema",
    "$id": "http://example.com/example.json",
    "type": "object",
    "title": "The root schema",
    "description": "The root schema comprises the entire JSON document.",
    "default": {},
    "required": [
        "name",
        "price"
    ],
    "properties": {
        "name": {
            "$id": "#/properties/name",
            "type": "string",
            "title": "The name schema",
            "description": "An explanation about the purpose of this instance.",
            "default": "",
            "examples": [
                "A green door"
            ]
        },
        "price": {
            "$id": "#/properties/price",
            "type": "number",
            "title": "The price schema",
            "description": "An explanation about the purpose of this instance.",
            "default": 0.0,
            "examples": [
                12.5
            ]
        }
    },
    "additionalProperties": true
},
  "display": {
    "title":
  }, optional
}

A credential template creator should be used to generate the schema object.

res:
{
  "manifest_uri": "uri of manifest", 
  
}

## Assign Manifest
The template is a data model with everything required for an issuer to issue a credential, as defined by the provider. This template then assigned to an issuer to complete it.

req: {
  "manifest_id": "",
  "issuers": [
    {
      "id": "did:key:12345"
    }
  ]
}

## List, Read, Update, Delete
//todo

## How manifests fit into presentation exchanges
https://identity.foundation/presentation-exchange/#presentation-definition

The presentation exchange defines two objects:

**Presentation Definition**

{
  "comment": "Note: VP, OIDC, DIDComm, or CHAPI outer wrapper would be here.",
  "presentation_definition": {
    "id": "32f54163-7166-48f1-93d8-ff217bdb0653",
    "input_descriptors": [
      {
        "id": "wa_driver_license",
        "name": "Washington State Business License",
        "purpose": "We can only allow licensed Washington State business representatives into the WA Business Conference",
        "schema": [{
            "uri": "https://licenses.example.com/business-license.json"
        }]
      }
    ]
  }
}

These have
- input_descriptors as a peer with `output_descriptors` in the credential manifest. input descriptors are used to describe the information required of a holder by a verifier. Output descriptors are used to describe the claims an issuer is offering to a holder. These work together nicely.

**Presentation Submission**

{
  
}

These map to

**Credential Application**

**Credential Fulfillment**

## Questions

### How do deal with contexts?
THe contexts in verifiable credentials provide meaningful metadata about the credentials.

**Option 1** Extend the json schema model with a new keyword `$context` to specify what each attribute's context is.

**Option 2**
Include a separate list of contexts and types, then match them to the list of attributes within the json schema.

## Next Steps
Given a json schema, create a credential manifest and return it.