Discussion: What would be in an AnonCreds "presentation request" OCA Bundle consist?

[swcurran]

We talked about what would be in an AnonCreds "presentation request" OCA Bundle such that the presentation request UX can be improved -- particularly in the areas of:

• Multilingual support
• An overall name/purpose for the presentation request
• A summary of the purpose/justification for the presentation request
• A label/information for the requested attributes, especially for predicates

This issue is written in the form of a spec (as if decisions have been made), but all aspects are open to discussion.

Context

A holder will receive a presentation request from a verifier. Before any UI is presented to the user, the holder's wallet will look into the holder storage to find the credentials that could be used to satisfy the presentation request. Once that is done, the possible response to the presentation request is put on the screen for the user. At that point the state of the flow could be:

• The Holder has exactly one set of credentials that satisfy the all parts of the presentation request.
• The Holder does not have a set of credentials that satisfy all parts of the presentation request.
• The Holder has more than one credential that satisfies some or all of the parts of the presentation request.

Further, for each credential that the Holder has, assume that they also have access to the OCA Bundle associated with that credential. As such, the Holder will already have access to a lot of OCA for Aries Bundles and the data therein. Of course, where there is no credential, or where there is no OCA Bundle, the holder would not have any extra information, other than perhaps the OCA Bundle from the presentation request.

OCA Presentation Request Data

We propose that the following OCA Overlays be included in the OCA Bundle for Presentation Requests. To help in understanding these, please see this set of Presentation Request templates that are currently in the BC Wallet.

• The ID of the presentation request should be used to find the associated OCA Bundle for the presentation request.
• Capture Base:
  • The list of all attributes in "name" and "names", plus the list of the attribute needed for each attribute.
    • The same attribute may be requested in multiple name/names entries.
    • For now, we will ignore that possibility, but keep in mind that we may need to differentiate the attribute names by where they appear in the presentation request.
  • The list of predicates in the form "predicate."
    • This is the item that will NEVER be in the source credential OCA Bundles so it is very important.
    • Like the attributes, the same attribute name could be used in multiple predicates, so we might need to do something about that.
  • As with all Capture Bases, the list of PII elements should be tracked.
• Meta Overlay (multilingual):
  • Name of Presentation Request
  • Description of Presentation Request
  • Justification for Request -- text about why the verifier is asking for the presentation request
• Label Overlay
• Information Overlay

There is no need for the other overlays that are used in OCA for Aries credentials because

• They are needed only when the holder has credentials (with data) to satisfy the request, and at that time, the holder will have the OCA Bundles for the credentials.
• The verifier may not be certain which credentials the holder will use to satisfy the request, so cannot know the data types anyway.
• For predicates, the data is always either a True or False.

• The branding is not needed, as the branding from the source credentials will be used.

  • This is the current suggestion, but should be considered further as we test using these OCA Bundles.

  On Screen Display

  The wallet will display for the user:

  • The name and possibly the description of the presentation request from the user, perhaps also with the Justification for request text inline or available via a popup.
  • For predicates, the label (and optional information popup) from the Presentation Request OCA Bundle
  • For any attributes that for which the holder does not have a credential, the Label (and optional information popup) from the Presentation Request bundle.
  • For all other attributes, the Label (and optional information popup) from the source credential to be used in satisfying the request.
  • For all attributes, a flag/indicator that the data element is sharing PII data, coming from OCA Presentation or OCA Source credential bundles.

[swcurran]

@amanji -- does this look right from our discussion? Please share with others that are interested.