README.md

0429: Prerequisites to Request Rich Presentation

• Authors: Brent Zundel, Ken Ebert
• Status: STALLED
• Since: 2024-04-03
• Status Note: No implementations have been created.
• Supersedes:
• Start Date: 2020-02-19
• Tags: feature, rich-schemas

Summary

Describes the prerequisites a verifier must ensure are in place before requesting a rich presentation.

Motivation

To inform verifiers of the steps they should take in order to make sure they have the necessary rich schema objects in place before they use them to request proofs.

Tutorial

Rich Schema Presentation Definition Workflow

1. The verifier checks his wallet or the ledger to see if the presentation definition already exists. (The verifier determines which attribute or predicates he needs a holder to present to satisfy the verifier's business rules. Presentation definitions specify desired attributes and predicates).
   1. If not, the verifier creates a new presentation definition and stores the presentation definition in his wallet locally and, optionally, anchors it to the verifiable data registry. (Anchoring the presentation definition to the verifiable data registry allows other verifiers to easily use it. It can be done by writing the full presentation definition's content to the ledger, or just writing a digital fingerprint/hash of the content.)
2. Using the presentation definition, request a presentation from the holder. The Present Proof Protocol 1.0 will be the model for another RFC containing minor modifications for presenting a proof based on verifiable credentials using the new rich schema objects.

Reference

• RFC 0250: Rich Schema Objects
• RFC 0420: Rich Schema Objects Common
• RFC XXXX: Aries Rich Schema Presentation Definitions
• RFC 0037: Present Proof Protocol 1.0

Unresolved questions

The RFC for Rich Schema Presentation Definitions is incomplete.

Implementations

The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.

Name / Link	Implementation Notes

|