This is a part of trustbloc/sandbox#382

This will allow registration of the rp-rest service.

Add connect feature between issuer adapter and wallet

RP makes OIDC request to adapter, adapter makes presentation req to wallet and wallet responds with presentation with consent credential (User is the holder of manifest credential) - without blinded routing

This scenario is strictly about the RP adapter fetching a verifiable presentation from the Issuer's adapter. The wallet will not provide any credentials at this point.

TLDR

All the RP adapter needs is a VP with two VCs:

• UserConsentCredential
• DIDDocCredential (contains the issuer's peer DID doc)

The RP Adapter will internally create a new connection record using its peer DID and the issuer's peer DID. Then, these credentials will be included in the request-presentation message as attachments.

Format of Credentials

UserConsentCredential

TODO (although for the moment the RP Adapter does not need to understand its format). Need to update this doc

Tasks

• Parse verifiable presentation #84
• parse issuer peer did doc #86
  • requires support for parsing peer DID Docs in aries-framework-go hyperledger-archives/aries-framework-go#1932 Juice not worth the squeeze. Will use did.ParseDocument() instead. The wallet should be using did.Doc.JSONBytes() to serialize the did doc properly.
  • partial support for parsing custom credentialSubjects in VCs in aries-framework-go - see example
• create connection record rp <-> issuer (example) #86
• capture and store RP's peer DID upon connection completion b/w user and RP adapter #94
• build and send request-presentation message (aries-framework-go already supports this) #100
• validate response
  • verify VP #100
  • json-ld context for issuer response vp #111
  • parse presentation submission #111
  • verify criteria in presentation definitions are met #108
• refactor CHAPI request #121
• refactor: embed did documents inside user consent VC #120
• fix: chapiResponseHandler should expect a presentation_submission, not just any VP #120
• return data to the RP #130
• user redirection:
  • redirect back to RP #165
  • show error page is validation fails #128

• refactor rp-adapter-vue to follow layout in edge-agent #37
• fetch presentation-exchange request and send via CHAPI #39
  • Leave placeholders or extension points to include additional stuff that will need to be included later (eg. oob invitation, etc)

part of #36

Also, see #31 (comment):

How does this impact running a cluster of adapters and also adapter restarts?

Note: in general, we want to avoid sticky sessions when possible.

... and check for adequate in-memory RDBMS implementations that we could use for test for all packages that require testing against a "real" DB.

Need to create a mock aries context provider. The current mock provider in aries, doesn't support Context completely.

part of #66

• Setup Hydra, RP Adapter, MySQL, trustbloc-did-method #74
• Scenarios:
  • Register RP tenant at both hydra and RP adapter #74
  • did-exchange with wallet #132
  • return data to the rp #147

Currently, leveldb is used as the backing storage for aries-framework-go. Update it to use SQL store, once its available in aries.

https://identity.foundation/presentation-exchange/

https://github.com/decentralized-identity/presentation-exchange/pull/14/files#diff-9308a2575ae14de31b25f4459ecfc604R437

API to retrieve the DIDExchange Invitation.

Can use github.com/xo/dburl

xo/dburl#15

The createRPTenantEndpoint should create publicDIDs for the tenants. This aligns with the principle of "adapters hide all the didcomm/vc complexity".

part of #60

Capture the RP's peerDID when the did-exchange connection with the wallet is established

Followup from #63 (comment)

• Redirect back to hydra when skipping #17
• Data access layer #18
• Register on OIDC Provider
• Redirect to OIDC provider when NOT skipping #21
• Save user, initial OIDC request from RP, access_token #21

part of #36

part of #57

part of #60

Use trustbloc/edge-core

Integrate aries agent - #26

See #55 (review)

The current implementation assumes an integration with an OIDC adapter for user authentication. Since there won't be user authentication at an OIDC provider for iteration 1, that leg of the flow must be short-circuited such that the user is always redirected to the consent screen where the CHAPI request will be delivered to their user agent.

The minimal steps for this flow are:

1. Fetch the login details from hydra
2. Search for rp.UserConnection with the clientID and the user Subject
   a. If none found, create one
3. Accept the login request at hydra
4. Fetch the consent details from hydra
5. Create presentationdefinition
6. Redirect to frontend

This is a followup to discussion in #13 (comment).

When the Hydra redirects the UA to the RP Adapter at /consent, the RP Adapter should create a new handle to the OIDC request details and then redirect to the frontend on /ui and pass that handle as a URL fragment. The frontend will later request the presentation-request at the backend using this handle.

We should support controlled schema migrations. We can use tools like https://github.com/golang-migrate/migrate or https://github.com/rubenv/sql-migrate

• Vue.JS
• Hydra
• Custom app
• Database