Feature: Authorized Presenters

[OR13]

Users should be able to store configurations in their wallet that help provide UI or software automation support for reducing friction associated with verifiable presentations.

For example the what-is-the-difference-between-authorized-keys-and-known-hosts-file-for-ssh

A holder may wish to configure their wallet to automatically store presentations from certain holders, without buffering them... or may wish to only buffer presentations that contain credentials that not in their "Authorized Presenters" list.

This object is similar to Connection, in that it relates to an established relationship between parties.

[OR13]

Related VC HTTP API PR: w3c-ccg/vc-api#168

[OR13]

I am proposing that this object by useful to determine if a presentation should be stored.... in pseudo code:

Holder 1 -> Notify -> Holder 2
Holder 1 <- Domain, Challenge <- Holder 2

Holder 1 -> Present -> Holder 2

...

Holder 2 Lookup AuthorizedPresenters if presentation is authorized (matches expectations)

Holder 2 store credentials in PendingPresentations

...

Holder 1 <- Receipt? <- Holder 2

[sudeshrshetty]

@OR13 Do you think we need new interfaces for these holder presentation exchange scenarios? (adding notify & present & authorizePresenter etc)

or based on query type we can modify existing wallet.query() interface to support some of steps in this flow.

[OR13]

@sudeshrshetty good question. I have been designing them as new interfaces... and am running into the stateful persistence issues related to them its all pretty experimental currently, but I am working on it here: transmute-industries/verifiable-data#30

once it feels like the api is good I will open a PR that should be easier to review.