diff --git a/concepts/0302-aries-interop-profile/README.md b/concepts/0302-aries-interop-profile/README.md index 899766138..70900d214 100644 --- a/concepts/0302-aries-interop-profile/README.md +++ b/concepts/0302-aries-interop-profile/README.md @@ -19,7 +19,7 @@ This RFC defines the process for the community of Aries agent builders to: An Aries Interop Profile (AIP) version provides a clearly defined set of versions of RFCs for Aries agent builders to target their agent implementation when they wish it to be interoperable with other agents supporting the same Aries Interop Profile version. The Aries Interop Profile versioning process is intended to provide clarity and predictability for Aries agent builders and others in the broader Aries community. The process is not concerned with proposing new, or evolving existing, RFCs, nor with the development of Aries code bases. -At all times, the [Reference](#reference) section of this RFC defines one or more current Aries Interop Profile versions -- a number and set of links to specific commits of concept and features RFCs, along with a list of all previous Aries Interop Profile versions. Several current Aries Interop Profile versions can coexist during periods when multiple major Aries Interop Profile versions are in active use (e.g. 1.x and 2.x). Each entry in the previous versions list includes a link to the commit of this RFC associated with that Aries Interop Profile version. The [Reference](#reference) section MAY include one ".next" version for each existing current major Aries Interop Profile versions. Such "next" versions are proposals for what is to be included in the next minor AIP version. +At all times, the [Reference](#reference) section of this RFC defines one or more current Aries Interop Profile versions -- a number and set of links to specific commits of concept and features RFCs, along with a list of all previous Aries Interop Profile versions. Several current Aries Interop Profile versions can coexist during periods when multiple major Aries Interop Profile versions are in active use (e.g. 1.x and 2.x). Each entry in the previous versions list includes a link to the commit of this RFC associated with that Aries Interop Profile version. The [Reference](#reference) section MAY include one `.next` version for each existing current major Aries Interop Profile versions. Such "next" versions are proposals for what is to be included in the next minor AIP version. Once a suitably populated Aries test suite is available, each Aries Interop Profile version will include a link to the relevant subset of test cases. The test cases will include only those targeting the specific versions of the concepts and features RFCs in that version of Aries Interop Profile. A process for maintaining the link between the Aries Interop Profile version and the test cases will be defined in this RFC once the Aries test suite is further evolved. @@ -47,7 +47,7 @@ The establishment of Aries Interop Profile versions defined by the Aries agent b This RFC MUST contain the current Aries Interop Profile versions as defined by a version number and a set of links to concept and feature RFCs which have been agreed to by a community of Aries agent builders. "Agreement" is defined as when the community agrees to merge a Pull Request (PR) to this RFC that affects an Aries Interop Profile version number and/or any of the links to concept and feature RFCs. PRs that do not impact the Aries Interop Profile version number or links can (in general) be merged with less community scrutiny. -Each link to a concept or feature RFCs MUST be to a specific commit of that RFC. RFCs in the list MAY be flagged as deprecated. Linked RFCs that reference external specs or standards MUST refer to as specific a version of the external resource as possible. +Each link to a concept or feature RFCs MUST be to a specific commit of that RFC. RFCs in the list MAY be flagged as deprecated. Linked RFCs that reference external specs or standards MUST refer to as specific a version of the external resource as possible. Aries Interop Profile versions SHOULD have a link (or links) to a version (specific commit) of a test suite (or test cases) which SHOULD be used to verify compliance with the corresponding version of Aries Interop Profile. Aries agent builders MAY self-report their test results as part of their entries in the list of agents. @@ -147,7 +147,7 @@ The following are the goals used in selecting RFC versions for inclusion in AIP - RFCs 0183 - Improve the low-level messaging cryptography and enable a transition to DIDComm 2.0 to improve the security of the communication paths between agents. - - RFCs 0044, 0360, 0334, 0587 + - RFCs 0044, 0360, 0334 - Use protocols and standards that support multiple ledger types and verifiable credential formats. - RFCs 0434, 0023, 0453, 0454 @@ -155,7 +155,7 @@ The following are the goals used in selecting RFC versions for inclusion in AIP - Where appropriate, enable standard mediator coordination capabilities for mobile agents and multi-tenant agencies. - RFC 0211 -### AIP 2.0 Clarification Changelog +#### AIP 2.0 Changelog by Pull Requests Since approval of the AIP 2.0 profile, the following RFCs have been clarified by updating the commit in the link to the RFC: @@ -167,76 +167,122 @@ Since approval of the AIP 2.0 profile, the following RFCs have been clarified by - 2022-06: RFC 0023 DID Exchange, RFC 0025 DIDComm Transports, RFC 0434 Out of Band - Pull request: [#739](https://github.com/hyperledger/aries-rfcs/pull/739) +- 2024-02: Clarifications and removals of RFCs that have been determined to be impractical for AIP 2.0. + - See the [AIP 2.0 RFC Removed](#aip-20-rfcs-removed) section for details about the removed RFCs + - See the updated [implementer's note on encryption envelopes in AIP 2.0](#implementers-note-about-didcomm-envelopes-and-the-accept-element) that highlights the removal of RFC 0587-encryption-envelope-v2. + - Pull request: [#814](https://github.com/hyperledger/aries-rfcs/pull/814) + +#### AIP 2.0 Changelog by Clarifications + +The original commit used in the definition of AIP 2.0 was: `b3a3942ef052039e73cd23d847f42947f8287da2` + +The following clarifications have been made to RFCs that make up AIP 2.0. This list excludes commits changed solely because of status changes: + +- RFC 0003 Protocols: A correction to the tic-tac-toe example protocol was made; clarifications and additional guidance about the handling of minor differences in protocols by implementations. +- RFC 0017 Attachments: A clarification was made around the use of base64url encoding/decoding. +- RFC 0441 Present Proof Best Practices: A convention for representing dates to enable simple "older than" predicates was added. +- RFC 0592 Indy Attachment Format: The encoding algorithm used for credential attributes was added from RFC 0036. +- RFC 0008 Message ID and Threading: Clarification on having an empty `~thread` on a first message. +- RFC 0519 Goal Codes: Added some commonly used Goal Codes. +- RFC 0015 Acks: Clarification that an "Ack" value should not be "Fail" and Acks relationship with RFC 0035 Problem Report. +- RFC 0023 DID Exchange: Status update to Adopted, added to example the use of a DID Rotate attachment to include a signature on the the DID. +- RFC 0035 Report Problem: Clarification that a `description.code` is required, clarification on conventions for warnings. +- RFC 0044 DIDComm File and MIME Types: Clarifications on fallbacks for the mime types and why, and on using JWEs. +- RFC 0211 Route Coordination: Clarification to add a missing comma to an example. +- RFC 0434 Out of Band: Clarification that did:peer:2 can be used for reuse. +- RFC 0627 Static Peer DIDs: Clarifications that reflect the transition to Peer DIDs 2 and 4. +- RFC 0592 Indy Attachments: Clarification on handling "unrevealed attributes" and on encoding integer strings as numbers (e.g. encoding both `"1"` vs. `1` as integers) +- RFC 0510 DIF Presentation Exchange Attachment: Correction of reference into the DIF spec that there is an "s" on "definitions" in `dif/presentation-exchange/definitions@v1.0` + #### Base Requirements RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Concept | [0003-protocols](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/concepts/0003-protocols) | [AIP V1.0, Reformatted](https://gist.github.com/swcurran/6976dc1fd1b10c51343cf3812288b345/revisions?diff=unified) +Concept | [0003-protocols](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/concepts/0003-protocols) | [AIP V1.0, Reformatted](https://gist.github.com/swcurran/6976dc1fd1b10c51343cf3812288b345/revisions?diff=unified) Concept | [0004-agents](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/concepts/0004-agents) | AIP V1.0, Unchanged -Concept | [0005-didcomm](https://github.com/hyperledger/aries-rfcs/tree/1b4b014246d19c865c9b5520b97fe0376a86d8c4/concepts/0005-didcomm) | [AIP V1.0, Minimally Updated](https://gist.github.com/swcurran/788195ea0bccec53e1f9fe3509034341/revisions?diff=unified) -Concept | [0008-message-id-and-threading](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/concepts/0008-message-id-and-threading) | [AIP V1.0, Updated](https://gist.github.com/swcurran/db72109ea4f2e336ac91f4fbab3f4048/revisions?diff=unified) -Concept | [0011-decorators](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/concepts/0011-decorators) | [AIP V1.0, Updated](https://gist.github.com/swcurran/04229583a509f12258352f9c85b9c9b6/revisions?diff=unified) +Concept | [0005-didcomm](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/concepts/0005-didcomm) | [AIP V1.0, Minimally Updated](https://gist.github.com/swcurran/788195ea0bccec53e1f9fe3509034341/revisions?diff=unified) +Concept | [0008-message-id-and-threading](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/concepts/0008-message-id-and-threading) | [AIP V1.0, Updated](https://gist.github.com/swcurran/db72109ea4f2e336ac91f4fbab3f4048/revisions?diff=unified) +Concept | [0011-decorators](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/concepts/0011-decorators) | [AIP V1.0, Updated](https://gist.github.com/swcurran/04229583a509f12258352f9c85b9c9b6/revisions?diff=unified) Concept | [0017-attachments](https://github.com/hyperledger/aries-rfcs/tree/7759addb1506d107fddec692403bbc9e55fe491f/concepts/0017-attachments) | [AIP V1.0, Updated](https://gist.github.com/swcurran/7d88f9866175af96a70e5c6c00fa0148/revisions?diff=unified) -Concept | [0020-message-types](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/concepts/0020-message-types) | [AIP V1.0, Updated](https://gist.github.com/swcurran/8f95c25b5c778426d3a47fe6d7c46c70/revisions?diff=unified)
Mandates message prefix `https://didcomm.org` for Aries Protocol messages. +Concept | [0020-message-types](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/concepts/0020-message-types) | [AIP V1.0, Updated](https://gist.github.com/swcurran/8f95c25b5c778426d3a47fe6d7c46c70/revisions?diff=unified)
Mandates message prefix `https://didcomm.org` for Aries Protocol messages. Concept | [0046-mediators-and-relays](https://github.com/hyperledger/aries-rfcs/tree/45b4233fcffda14f1339380ae2233289f21296b0/concepts/0046-mediators-and-relays) | [AIP V1.0, Minimally Updated](https://gist.github.com/swcurran/2486b63615f7a36c1e997b6c8b10c245/revisions?diff=unified) Concept | [0047-json-LD-compatibility](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/concepts/0047-json-ld-compatibility) | [AIP V1.0, Minimally Updated](https://gist.github.com/swcurran/8ef311d793fc6964328687af3c0efd34/revisions?diff=unified) Concept | [0050-wallets](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/concepts/0050-wallets) | AIP V1.0, Unchanged Concept | [0094-cross-domain messaging](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/concepts/0094-cross-domain-messaging) | [AIP V1.0, Updated](https://gist.github.com/swcurran/e3f27e3ab85a260aaf279352ecc4e1fb/revisions?diff=unified) -Concept | [0519-goal-codes](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/concepts/0519-goal-codes) | :new: -Feature | [0015-acks](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0015-acks) | [AIP V1.0, Updated](https://gist.github.com/swcurran/81af391bfd79539edec530150045fe51/revisions?diff=unified) -Feature | [0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/features/0019-encryption-envelope) | [AIP V1.0, Updated](https://gist.github.com/swcurran/c652dfd39706e50be4145568797e667a/revisions?diff=unified)
See envelope note below +Concept | [0519-goal-codes](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/concepts/0519-goal-codes) | :new: +Feature | [0015-acks](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0015-acks) | [AIP V1.0, Updated](https://gist.github.com/swcurran/81af391bfd79539edec530150045fe51/revisions?diff=unified) +Feature | [0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0019-encryption-envelope) | [AIP V1.0, Updated](https://gist.github.com/swcurran/c652dfd39706e50be4145568797e667a/revisions?diff=unified)
See envelope note below Feature | [0023-did-exchange](https://github.com/hyperledger/aries-rfcs/tree/bf3d796cc33ce78ed7cde7f5422b10719a68be21/features/0023-did-exchange) | :new: -Feature | [0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/f39481e92ad1a10dbc499cd4931a08c3497cee3f/features/0025-didcomm-transports) | [AIP V1.0, Minimally Updated](https://gist.github.com/swcurran/1e64cba5f6c524d38ad596209df090df/revisions?diff=unified) -Feature | [0035-report-problem](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0035-report-problem) | [AIP V1.0, Updated](https://gist.github.com/swcurran/d9432abc436e6a069d6ffcd41dc86060/revisions?diff=unified) -Feature | [0044-didcomm-file-and-mime-types](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0044-didcomm-file-and-mime-types) | :new: -Feature | [0048-trust-ping](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/features/0048-trust-ping) | :new: +Feature | [0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0025-didcomm-transports) | [AIP V1.0, Minimally Updated](https://gist.github.com/swcurran/1e64cba5f6c524d38ad596209df090df/revisions?diff=unified) +Feature | [0035-report-problem](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0035-report-problem) | [AIP V1.0, Updated](https://gist.github.com/swcurran/d9432abc436e6a069d6ffcd41dc86060/revisions?diff=unified) +Feature | [0044-didcomm-file-and-mime-types](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0044-didcomm-file-and-mime-types) | :new: +Feature | [0048-trust-ping](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0048-trust-ping) | :new: Feature | [0183-revocation-notification](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/features/0183-revocation-notification) | :new: Feature | [0360-use-did-key](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/features/0360-use-did-key) | :new: -Feature | [0434-outofband](https://github.com/hyperledger/aries-rfcs/tree/2bc7db66d15a55d70ce5bd16b2513a853c9d5749/features/0434-outofband) | :new: +Feature | [0434-outofband](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0434-outofband) | :new: Feature | [0453-issue-credential-v2](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0453-issue-credential-v2) | Update to V2 Protocol Feature | [0454-present-proof-v2](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0454-present-proof-v2) | Update to V2 Protocol +Feature | [0627-static-peer-dids](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0627-static-peer-dids) | The use of static peer DIDs in Aries has evolved and all AIP 2.0 implementations should be using DID Peer types 4 (preferred) or 2. Feature | [0557-discover-features-v2](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0557-discover-features-v2) | :new: -Feature | [0627-static-peer-dids](https://github.com/hyperledger/aries-rfcs/tree/4739fbf6de07a54c3fee072bd85741422730b3cd/features/0627-static-peer-dids) | :new: -Feature | [0317-please-ack](https://github.com/hyperledger/aries-rfcs/tree/9ff2cab45487a1f6f74254abc9134419f2ad5858/features/0317-please-ack) | :new: #### MEDIATE: Mediator Coordination RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Feature | [0211-route-coordination](https://github.com/hyperledger/aries-rfcs/tree/55e1e1c6e339ef0843268b4f3349b95cb7bd49a5/features/0211-route-coordination) | :new: +Feature | [0211-route-coordination](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0211-route-coordination) | :new: Feature | [0092-transport-return-route](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0092-transport-return-route) | :new: #### INDYCRED: Indy Based Credentials RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Feature | [0592-indy-attachments](https://github.com/hyperledger/aries-rfcs/tree/26344513082af4d76c77b8b4f5064e72d0a83b58/features/0592-indy-attachments) | :new: Evolved from AIP V1.0 +Feature | [0592-indy-attachments](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0592-indy-attachments) | :new: Evolved from AIP V1.0 Concept | [0441-present-proof-best-practices](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/concepts/0441-present-proof-best-practices) | :new: #### LDCRED: JSON-LD Based Credentials RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Feature | [0593-json-ld-cred-attach](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0593-json-ld-cred-attach) | :new: -Feature | [0510-dif-pres-exch-attach](https://github.com/hyperledger/aries-rfcs/tree/7a44f650d3cebf5b3047c1680618978393a497d5/features/0510-dif-pres-exch-attach) | :new: +Feature | [0593-json-ld-cred-attach](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0593-json-ld-cred-attach) | :new: +Feature | [0510-dif-pres-exch-attach](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0510-dif-pres-exch-attach) | :new: #### BBSCRED: BBS+ Based Credentials RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Feature | [0593-json-ld-cred-attach](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0593-json-ld-cred-attach) | :new: +Feature | [0593-json-ld-cred-attach](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0593-json-ld-cred-attach) | :new: Feature | [0646-bbs-credentials](https://github.com/hyperledger/aries-rfcs/blob/7a44f650d3cebf5b3047c1680618978393a497d5/features/0646-bbs-credentials/README.md) | :new: -Feature | [0510-dif-pres-exch-attach](https://github.com/hyperledger/aries-rfcs/tree/7a44f650d3cebf5b3047c1680618978393a497d5/features/0510-dif-pres-exch-attach) | :new: +Feature | [0510-dif-pres-exch-attach](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0510-dif-pres-exch-attach) | :new: + +#### CHAT: Chat related features -#### DIDCOMMV2PREP: DIDComm v2 Prep RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Feature | [0587-encryption-envelope-v2](https://github.com/hyperledger/aries-rfcs/tree/4e78319e5f79df2003ddf37f8f497d0fae20cc63/features/0587-encryption-envelope-v2) | :new:
See envelope note below +Feature | [0095-basic-message](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0095-basic-message) | :new: + +#### AIP 2.0 RFCs Removed + +> [!WARNING] +> After discussion amongst the Aries implementers, the following RFCs initially +> in AIP 2.0 have been **removed** as both never implemented (as far as we know) +> and impractical to implement. Since the RFCs have never been implemented, +> their removal does not have a practical impact on implementations. Commentary +> below the table listing the removed RFCs provides the reasoning for the removal of each RFC. -#### CHAT: Chat related features RFC Type | RFC/Link to RFC Version | Note --- | --- | --- -Feature | [0095-basic-message](https://github.com/hyperledger/aries-rfcs/tree/b3a3942ef052039e73cd23d847f42947f8287da2/features/0095-basic-message) | :new: +Feature | [0317-please-ack](https://github.com/hyperledger/aries-rfcs/tree/9ff2cab45487a1f6f74254abc9134419f2ad5858/features/0317-please-ack) | Removed from AIP 2.0 +Feature | [0587-encryption-envelope-v2](https://github.com/hyperledger/aries-rfcs/tree/c3b0e2120ad24810598375663b6922b980f85d00/features/0587-encryption-envelope-v2) | Removed from AIP 2.0 + +- **0317-please-ack**: While the idea of a generic ACK request to be sent either immediately `on receipt`, or `after processing` seemed like a good idea, attempts to implement the feature proved ill-advised. + - The feature was never implemented, and there have been (as far as we know) no requests for its implementation. A good idea in theory, but not needed in practice. + - The `on receipt` use of `please-ack` might be feasible as a generic feature, but does not appear to be useful except in protocol specific ways, such as in implementing a texting protocol to get "read receipts". However, even in that case, it is not useful for the existing 0095-basic-messaging protocol, because the protocol will be complete (and likely deleted) before the `ack` can be sent back to the sender. When an `on receipt` ACK is needed, it is much preferred to add it in a protocol specific way vs. in a generic way. + - The `after processing` use of `please-ack` turned out to be impossible because its introduction changes every protocol state machine in protocol specific ways. We have determined that it is not possible to "generically" (without changing each protocol) to add such a feature and so we have decided that if there is a use case of `please-ack`-style functionality in a given protocol, it should be added/included in that protocol. Further, no one has requested that the feature be used in any implementation. + - See the [RFC 0317 Please Ack](https://github.com/hyperledger/aries-rfcs/tree/main/features/0317-please-ack) for more details on it's change of status to `RETIRED` and links to unmerged PRs that attempted to design and implement the functionality. +- 0587-encryption-envelope-v2 + - While this RFC will be crucial when the transition to DIDComm v2 is started, it is not of use until then, and hence not applicable to AIP 2.0. + +[DID Peer]: https://identity.foundation/peer-did-method-spec/ #### AIP v2.0 Test Suite @@ -244,27 +290,18 @@ The [Aries Agent Test Harness](https://github.com/hyperledger/aries-agent-test-h #### Implementers Note about DIDComm Envelopes and the `ACCEPT` element -AIP 2.0 contains two RFCs that reference envelopes 0019-encryption-envelope and 0587-encryption-envelope-v2 (links above). +> [!WARNING] +> The following paragraph is struck out as no longer relevant, since the +> 0587-encryption-envelope-v2 RFC has been removed from AIP 2.0. The upcoming +> (to be defined) AIP 3.0 will include the transition from DIDComm v1 to the +> next DIDComm generation, and at that time, the 0587-encryption-envelope-v2 +> will again be relevant. + +~~AIP 2.0 contains two RFCs that reference envelopes 0019-encryption-envelope and 0587-encryption-envelope-v2 (links above). The important feature that Aries implementers should understand to differentiate which envelope format can or is being used by an agent is the `accept` element of the DIDComm service endpoint and the out-of-band `invitation` message. If the `accept` element is not present, the agent can only use the RFC 0019-encryption-envelope present. If it is present, the values indicate the envelope format(s) -the agent does support. See the RFCs for additional details. - -#### Changelog - AIP 2.0 - -The original commit used in the definition of AIP 2.0 was: b3a3942ef052039e73cd23d847f42947f8287da2 - -The following clarifications have been made to RFCs that make up AIP 2.0: - -- RFC 0003 Protocols: A correction to the tic-tac-toe example protocol was made. -- RFC 0017 Attachments: A clarification was made around the use of base64url encoding/decoding. -- RFC 0434 Out of Band: The RFC status was changed to "Accepted." -- RFC 0627 Static Peer DIDs: The RFC status was changed to "Accepted." -- RFC 0441 Present Proof Best Practices: A convention for representing dates to enable simple "older than" predicates was added. -- RFC 0510 DIF Presentation Exchange Attachment: The RFC Status was changed to "Accepted." -- RFC 0646 BBS Credentials: The RFC Status was changed to "Accepted." -- RFC 0317 Please Ack: The RFC Status was changed to "Accepted" and added to the AIP 2.0 base requirements list. Original discussion included the please ack decorator, but it wasn't added to the AIP 2.0 list before releasing AIP 2.0. -- RFC 0592 Indy Attachment Format: The encoding algorithm used for credential attributes was added from RFC 0036. +the agent does support. See the RFCs for additional details.~~ ### Previous Versions diff --git a/concepts/0519-goal-codes/README.md b/concepts/0519-goal-codes/README.md index 7d4a67eb3..eed2b9718 100644 --- a/concepts/0519-goal-codes/README.md +++ b/concepts/0519-goal-codes/README.md @@ -156,6 +156,12 @@ Create a relationship. Carries the meaning implied today by a LinkedIn invitation to connect or a Facebook "Friend" request. Could be as limited as creating a DIDComm Connection. +##### `aries.vc.verifier.once` + +Create a DIDComm connection for the sole purpose of doing the one-time execution of a [Present Proof](/features/0454-present-proof-v2/README.md) protocol. Once the protocol execution is complete, both sides **SHOULD** delete the connection, as it will not be used again by either side. + +The purpose of the goal code flow is to accomplish the equivalent of a "connection-less" present proof by having the agents establish a DIDComm connection, execute the present proof protocol, and delete the connection. The need for this goal code is when an actual connection-less present proof cannot be used because the [out-of-band](/features/0434-outofband/README.md) (OOB) message (including the presentation request) is too large for the transport being used--most often a QR code (although it may be useful for Bluetooth scenarios as well)--and a URL shortner option is not available. By using a one-time connection, the OOB message is small enough to fit into easily into a QR code, the present proof protocol can be executed using the established connection, and at the end of the interaction, no connection remains for either side to use or manage. + ## 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. diff --git a/features/0317-please-ack/README.md b/features/0317-please-ack/README.md index d5a1d9099..26d238cf2 100644 --- a/features/0317-please-ack/README.md +++ b/features/0317-please-ack/README.md @@ -1,12 +1,30 @@ # Aries RFC 0317: Please ACK Decorator -- Authors: [Daniel Hardman](daniel.hardman@gmail.com), [Timo Glastra](mailto:timo@animo.id) -- Status: [ACCEPTED](/README.md#accepted) +- Authors: [Daniel Hardman](mailto:daniel.hardman@gmail.com), [Timo Glastra](mailto:timo@animo.id) +- Status: [RETIRED](/README.md#retired) - Since: 2019-12-26 -- Status Note: Separated from the ACK protocol. A lot of complex features were removed for inclusion in AIP 2.0 (see note at bottom) +- Status Note: Attempts at implementation demonstrate that a general purpose `~please_ack` capability is not practical, and needs to be implemented on a per protocol basis, for protocols where the functionality makes sense. - Start Date: 2018-12-26 - Tags: [feature](/tags.md#feature), [decorator](/tags.md#decorator) +## Retirement of `~please_ack` + +The `please_ack` decorator was initially added to [Aries Interop Protocol 2.0]. However, this was done prior to attempts at an implementation. When such an attempt was made, it was found that the decorator is not practical as a general purpose mechanism. The capability assumed that the feature would be general purpose and could be applied outside of the protocols with which it was used. That assumption proved impossible to implement. The inclusion of the `~please_ack` decorator cannot be implemented without altering any protocol with which it is used, and so it is not practical. Instead, any protocols that can benefit from such a feature can be extended to explicitly support the feature. + +For the `"on": ["OUTCOME"]` type of ACK, the problem manifests in two ways. First, the definition of `OUTCOME` is protocol (and in fact, protocol message) specific. The definition of "complete" for each message is specific to each message, so there is no "general purpose" way to know when an `OUTCOME` ACK is to be sent. Second, the addition of a `~please_ack` decorator changes the protocol state machine for a given protocol, introducing additional states, and hence, additional state handling. Supporting `"on": ["OUTCOME"]` processing requires making changes to all protocols, which would be better handled on a per protocol basis, and where useful (which, it was found, is rare), adding messages and states. For example, what is the point of an extra `ACK` message on an `OUTCOME` in the middle of a protocol that itself results in the sending of the response message? + +Our experimentation found that it would be easier to achieve a general purpose `"on": ["RECEIPT"]` capability, but even then there were problems. Most notably, the capability is most useful when added to the last message of a protocol, where the message sender would like confirmation that the recipient got the message. However, it is precisely that use of the feature that also introduces breaking changes to the protocol state machine for the protocols to which it applies, requiring per protocol updates. So while the feature would be marginally useful in some cases, the complexity cost of the capability -- and the lack of demand for its creation -- led us to retire the entire RFC. + +For more details on the great work done by [Alexander Sukhachev @alexsdsr](https://github.com/alexsdsr), please see these pull requests, including both the changes proposed in the PRs, and the subsequent conversations about the features. + +- [Aries Cloud Agent Python PR 2540 - PleaseAck.md document](https://github.com/hyperledger/aries-cloudagent-python/pull/2540) +- [Aries Cloud Agent Python PR 2546 - DRAFT: please_ack support PoC for the 0453-issue-credential-v2 protocol](https://github.com/hyperledger/aries-cloudagent-python/pull/2546) +- [Aries RFCs - Update the 'unresolved questions' section of the 0317-please-ack RFC](https://github.com/hyperledger/aries-rfcs/pull/801) + +Much thanks for Alexander for the effort he put into trying to implement this capability. + +[Aries Interop Protocol 2.0]: https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0302-aries-interop-profile#aries-interop-profile-version-20 + ## Summary Explains how one party can request an acknowledgment to and clarify the status of processes. diff --git a/features/0453-issue-credential-v2/README.md b/features/0453-issue-credential-v2/README.md index 92dc58173..72f5b01fe 100644 --- a/features/0453-issue-credential-v2/README.md +++ b/features/0453-issue-credential-v2/README.md @@ -10,7 +10,8 @@ ## Version Change Log -- Version 2.0 is the current version +- 20240311 Removed references to payments in the protocol to clarify to those new to the protocol that they have not been implemented by anyone. +- 20240313 Version 2.0 is the current version For a period of time, versions 2.1 and 2.2 where defined in this RFC. Those definitions were added prior to any implementations, and to date, there are no @@ -219,18 +220,17 @@ Description of fields: - `formats` -- contains an entry for each `offers~attach` array entry, providing the the value of the attachment `@id` and the verifiable credential format and version of the attachment. Accepted values for the `format` items are provided in the per format "Attachment" sections immediately below. - `offers~attach` -- an array of attachments that further define the credential being offered. This might be used to clarify which formats or format versions will be issued. -The Issuer may add a [`~payment-request` decorator](../0075-payment-decorators/README.md#payment_request) to this message to convey the need for payment before issuance. See the [payment section below](#payments-during-credential-exchange) for more details. - It is possible for an Issuer to add a [`~timing.expires_time` decorator](../0032-message-timing/README.md#tutorial) to this message to convey the idea that the offer will expire at a particular point in the future. Such behavior is not a special part of this protocol, and support for it is not a requirement of conforming implementations; the `~timing` decorator is simply a general possibility for any DIDComm message. We mention it here just to note that the protocol can be enriched in composable ways. ##### Offer Attachment Registry Credential Format | Format Value | Link to Attachment Format | Comment | ---- | --- | --- | --- | -DIF Credential Manifest | `dif/credential-manifest@v1.0` | [`offer-credential` attachment format](../0511-dif-cred-manifest-attach/README.md#offer-credential-attachment-format) | | -Hyperledger Indy Credential Abstract | `hlindy/cred-abstract@v2.0` | [`cred abstract` format](../0592-indy-attachments/README.md#cred-abstract-format) | | -Linked Data Proof VC Detail | `aries/ld-proof-vc-detail@v1.0` | [`ld-proof-vc-detail` attachment format](../0593-json-ld-cred-attach/README.md#ld-proof-vc-detail-attachment-format) | | -Hyperledger AnonCreds Credential Offer | `anoncreds/credential-offer@v1.0` | [`Credential Offer` format](../0771-anoncreds-attachments/README.md#credential-offer-format)| | +--- | --- | --- | --- | +DIF Credential Manifest | `dif/credential-manifest@v1.0` | [`offer-credential` attachment format](../0511-dif-cred-manifest-attach/README.md#offer-credential-attachment-format) | +Hyperledger Indy Credential Abstract | `hlindy/cred-abstract@v2.0` | [`cred abstract` format](../0592-indy-attachments/README.md#cred-abstract-format)| +Linked Data Proof VC Detail | `aries/ld-proof-vc-detail@v1.0` | [`ld-proof-vc-detail` attachment format](../0593-json-ld-cred-attach/README.md#ld-proof-vc-detail-attachment-format) | +Hyperledger AnonCreds Credential Offer | `anoncreds/credential-offer@v1.0` | [`Credential Offer` format](../0771-anoncreds-attachments/README.md#credential-offer-format)| +W3C VC - Data Integrity Proof Credential Offer | `didcomm/w3c-di-vc-offer@v0.1` | [`Credential Offer` format](../0809-w3c-data-integrity-credential-attachment/README.md#credential-offer-attachment-format)| #### Request Credential @@ -269,16 +269,15 @@ Description of Fields: - `formats` -- contains an entry for each `requests~attach` array entry, providing the the value of the attachment `@id` and the verifiable credential format and version of the attachment. Accepted values for the `format` items are provided in the per format "Attachment" sections immediately below. - `requests~attach` -- an array of [attachments](../../concepts/0017-attachments/README.md) defining the requested formats for the credential. -This message may have a [`~payment-receipt` decorator](../0075-payment-decorators/README.md#payment_receipt) to prove to the Issuer that the potential Holder has satisfied a payment requirement. See the [payment section below](#payments-during-credential-exchange). - ##### Request Attachment Registry Credential Format | Format Value | Link to Attachment Format | Comment | ---- | --- | --- | --- | -DIF Credential Manifest | `dif/credential-manifest@v1.0` | [`request-credential` attachment format](../0511-dif-cred-manifest-attach/README.md#request-credential-attachment-format) | | -Hyperledger Indy Credential Request | `hlindy/cred-req@v2.0` | [`cred request` format](../0592-indy-attachments/README.md#cred-request-format) | | -Linked Data Proof VC Detail | `aries/ld-proof-vc-detail@v1.0` | [`ld-proof-vc-detail` attachment format](../0593-json-ld-cred-attach/README.md#ld-proof-vc-detail-attachment-format) | | -Hyperledger AnonCreds Credential Request | `anoncreds/credential-request@v1.0` | [`Credential Request` format](../0771-anoncreds-attachments/README.md#credential-request-format) | | +--- | --- | --- | --- | +DIF Credential Manifest | `dif/credential-manifest@v1.0` | [`request-credential` attachment format](../0511-dif-cred-manifest-attach/README.md#request-credential-attachment-format) | +Hyperledger Indy Credential Request | `hlindy/cred-req@v2.0` | [`cred request` format](../0592-indy-attachments/README.md#cred-request-format)| +Linked Data Proof VC Detail | `aries/ld-proof-vc-detail@v1.0` | [`ld-proof-vc-detail` attachment format](../0593-json-ld-cred-attach/README.md#ld-proof-vc-detail-attachment-format) | +Hyperledger AnonCreds Credential Request | `anoncreds/credential-request@v1.0` | [`Credential Request` format](../0771-anoncreds-attachments/README.md#credential-request-format)| +W3C VC - Data Integrity Proof Credential Request | `didcomm/w3c-di-vc-request@v0.1` | [`Credential Request` format](../0809-w3c-data-integrity-credential-attachment/README.md#credential-request-attachment-format)| #### Issue Credential @@ -323,10 +322,11 @@ If the issuer wants an acknowledgement that he issued credential was accepted, t ##### Credentials Attachment Registry Credential Format | Format Value | Link to Attachment Format | Comment | ---- | --- | --- | --- | -Linked Data Proof VC | `aries/ld-proof-vc@v1.0` | [`ld-proof-vc` attachment format](../0593-json-ld-cred-attach/README.md#ld-proof-vc-attachment-format) | | -Hyperledger Indy Credential | `hlindy/cred@v2.0` | [credential format](../0592-indy-attachments/README.md#credential-format) | | -Hyperledger AnonCreds Credential| `anoncreds/credential@v1.0` | [`Credential` format](../0771-anoncreds-attachments/README.md#credential-format) | | +--- | --- | --- | --- | +Linked Data Proof VC | `aries/ld-proof-vc@v1.0` | [`ld-proof-vc` attachment format](../0593-json-ld-cred-attach/README.md#ld-proof-vc-attachment-format) | +Hyperledger Indy Credential | `hlindy/cred@v2.0` | [credential format](../0592-indy-attachments/README.md#credential-format)| +Hyperledger AnonCreds Credential| `anoncreds/credential@v1.0` | [`Credential` format](../0771-anoncreds-attachments/README.md#credential-format)| +W3C VC - Data Integrity Proof Credential | `didcomm/w3c-di-vc@v0.1` | [`Credential` format](../0809-w3c-data-integrity-credential-attachment/README.md#credential-attachment-format)| #### Adopted Problem Report @@ -371,20 +371,6 @@ Threading can be used to initiate a [sub-protocol](../../concepts/0003-protocols If threading were added to all of the above messages, a `~thread` decorator would be present, and later messages in the flow would reference the `@id` of earlier messages to stitch the flow into a single coherent sequence. Details about threading can be found in the [0008: Message ID and Threading](../../concepts/0008-message-id-and-threading/README.md) RFC. -## Payments during credential exchange - -Credentialing ecosystems may wish to associate credential issuance with payments by fiat currency or tokens. This is common with non-digital credentials today; we pay a fee when we apply for a passport or purchase a plane ticket. Instead or in addition, some circumstances may fit a mode where payment is made each time a credential is *used*, as when a Verifier pays a Prover for verifiable medical data to be used in research, or when a Prover pays a Verifier as part of a workflow that applies for admittance to a university. For maximum flexibility, we mention payment possibilities here as well as in the sister [0037: Present Proof](../0037-present-proof/README.md) RFC. - -### Payment decorators - -Wherever they happen and whoever they involve, payments are accomplished with optional payment decorators. See [0075: Payment Decorators](../0075-payment-decorators/README.md). - -### Payment flow - -A `~payment-request` may decorate a Credential Offer from Issuer to Holder. When they do, a corresponding `~payment-receipt` should be provided on the Credential Request returned to the Issuer. - -During credential presentation, the Verifier may pay the Holder as compensation for Holder for disclosing data. This would require a `~payment-request` in a Presentation Proposal message, and a corresponding `~payment-receipt` in the subsequent Presentation Request. If such a workflow begins with the Presentation Request, the Prover may sending back a Presentation (counter-)Proposal with appropriate decorator inside it. - ### Limitations Smart contracts may be missed in ecosystem, so operation "issue credential after payment received" is not atomic. It’s possible case that malicious issuer will charge first and then will not issue credential in fact. But this situation should be easily detected and appropriate penalty should be applied in such type of networks. diff --git a/features/0804-didcomm-rpc/README.md b/features/0804-didcomm-rpc/README.md new file mode 100644 index 000000000..14d8d7676 --- /dev/null +++ b/features/0804-didcomm-rpc/README.md @@ -0,0 +1,420 @@ +# 0804: DIDComm Remote Procedure Call (DRPC) + +- Authors: [Clecio Varjao](clecio.varjao@gov.bc.ca) (BC Gov), [Stephen Curran](swcurran@cloudcompass.ca) (BC Gov), [Akiff Manji](amanji@petridish.dev) (BC Gov) +- Status: [PROPOSED](/README.md#proposed) +- Since: 2023-11-29 +- Status Note: An evolution of the HTTP over DIDComm protocol to enable an Agent to request an arbitrary service from a connected Agent and get a response. +- Supersedes: +- Start Date: 2023-11-29 +- Tags: [feature](/tags.md#feature), [protocol](/tags.md#protocol) + +## Summary + +The DIDComm Remote Procedure Call (DRPC) protocol enables a [JSON-RPC]-based +request-response interaction to be carried out across a DIDComm channel. The +protocol is designed to enable custom interactions between connected agents, and +to allow for the rapid prototyping of experimental DIDComm protocols. An agent +sends a DIDComm message to request a [JSON-RPC] service be invoked by another +agent, and gets back the [JSON-RPC]-format response in subsequent DIDComm +message. The protocol enables any request to be conveyed that the other agent +understands. Out of scope of this protocol is how the requesting agent discovers +the services available from the responding agent, and how the two agents know +the semantics of the specified [JSON-RPC] requests and responses. By using +DIDComm between the requesting and responding agents, the security and privacy +benefits of DIDComm are accomplished, and the generic parameters of the requests +allow for flexibility in how and where the protocol can be used. + +[JSON-RPC]: https://www.jsonrpc.org/specification + +## Motivation + +There are several use cases that are driving the initial need for this protocol. + +### App Attestation + +A mobile wallet needs to get an [app attestation] verifiable credential from +the wallet publisher. To do that, the wallet and publisher need to exchange +information specific to to the attestation process with the Google and Apple +stores. The sequence is as follows: + +- The wallet decides (for some reason) it needs an App Attestation credential + from its publisher. +- If not already available, a DIDComm connection between the wallet and the + attestation service is created. +- The wallet uses the DRPC protocol to request a nonce from the service to be + used in the attestation. The service responds with the nonce. +- The wallet uses a new instance of the DRPC protocol to request the attestation + be performed. The service responds with the status of the attestation process. +- The service completes the business process by initiating an Issue Credential + process to issue an attestation verifiable credential. + +The wallet and service are using instances of three protocols (two DRPC and one +Issue Credential) to carry out a full business process. Each participant must +have knowledge of the full business process--there is nothing inherent in the +DRPC protocol about this process, or how it is being used. The DRPC protocol is +included to provide a generic request-response mechanism that alleviates the +need for formalizing special purpose protocols. + +> App attestation is a likely candidate for a having its own DIDComm protocol. +> This use of DRPC is ideal for developing and experimenting with the necessary +> agent interactions before deciding on if a use-specific protocol is needed and +> its semantics. + +[app attestation]: https://developer.apple.com/documentation/devicecheck + +### Video Verification Service + +A second example is using the DRPC protocol is to implement a custom video +verification service that is used by a specific mobile wallet implementation and +a proprietary backend service prior to issuing a credential to the wallet. Since +the interactions are to a proprietary service, so an open specification does not +make sense, but the use of DIDComm is valuable. In this example, the wallet +communicates over DIDComm to a Credential Issuer agent that (during +verification) proxies the requests/responses to a backend ("behind the +firewall") service. The wallet is implemented to use DRPC protocol instances to +initiate the verification and receive the actions needed to carry out the steps +of the verification (take picture, take video, instruct movements, etc.), +sending to the Issuer agent the necessary data. The Issuer conveys the requests +to the verification service and the responses back to the mobile wallet. At the +end of the process, the Issuer can see the result of the process, and decide on +the next actions between it and the mobile wallet, such as issuing a credential. + +Again, after using the DRPC protocol for developing and experimenting with the +implementation, the creators of the protocol can decide to formalize their own +custom, end-to-end protocol, or continue to use the DRPC protocol instances. +Important is that they can begin development without doing any Aries frameworks +customizations or plugins by using DRPC. + +## Tutorial + +### Name and Version + +This is the DRPC protocol. It is uniquely identified by the URI: + + "https://didcomm.org/drpc/1.0" + +### Key Concepts + +> This RFC assumes that you are familiar with [DID communication]. + +[DID communication]: /concepts/0005-didcomm/README.md + +The protocol consists of a DIDComm `request` message carrying an arbitrary +[JSON-RPC] request to a responding agent, and a second message that carries the +result of processing the request back to the client of the first message. The +interpretation of the request, how to carry out the request, the content of the +response, and the interpretation of the response, are all up to the business +logic (controllers) of the participating agents. There is no discovery of remote +services offered by agents--it is assumed that the two participants are aware of +the DRPC capabilities of one another through some other means. For example, from +the [App Attestation use case](#app-attestation), functionality to carry out the +app attestation process, and the service to use it is built into the mobile wallet. + +Those unfamiliar with [JSON-RPC], the `` is that it is a very simple +request response protocol using JSON where the only data shared is: + +- a `method` that defines what needs to be done, +- some `params` in JSON that are up to the requester/server to agree on, and +- an (optional) `id` to connect the response to the request. + +The response is likewise simple: + +- a `result` item if the invocation completed successful containing the return results, +- an `error` item if the invocation failed, containing details about the failure, and +- the `id` from the request. + +An example of a simple [JSON-RPC] request/response pair from the specification is: + +```json +--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} +<-- {"jsonrpc": "2.0", "result": 19, "id": 1} +``` + +A [JSON-RPC] request may be a batch of requests, each with a different `id` value, +and the response a similar array, with an entry for each of the requests. + +[JSON-RPC] follows a similar "parameters defined by the message type" pattern as +DIDComm. As a result, in this protocol we do not need to add any special +handling around the `params` such as Base64 encoding, signing, headers and so +on, as the parties interacting with the protocol by definition must have a +shared understanding of the content of the `params` and can define any special +handling needed amongst themselves. + +It is expected (although not required) that an Aries Framework receiving a DRPC +message will simply pass to its associated "business logic" (controller) the +request from the client, and wait on the controller to provide the response +content to be sent back to the original client. Apart from the messaging processing +applied to all inbound and outbound messages, the Aries Framework will not +perform any of the actual processing of the request. + +### Roles + +There are two roles, adopted from the [JSON-RPC] specification, in the protocol +`client` and `server`: + +- The `client` initiates the protocol, sending a request to the `server`. +- The `server` carries out the request however they see fit. The `server` + may process the request themselves, or might invoke another service to process + the request. The `server` might be unable or unwilling to carry out the + request. +- The `server` returns the response from the request in a message to the `client`. + +### States + +#### Client States + +The `client` agent goes through the following states: + +- request-sent +- completed + +The state transition table for the `client` is: + +| State / Events | Send Request | Receive Response | +| ----------------------- | ---------------------------------- | ------------------------------- | +| *Start* | Transition to
**request-sent** | | +| request-sent | | Transition to
**complete** | +| completed | | | +| problem-report received | | Transition to
**abandoned** | +| abandoned | | | + +#### Server States + +The `server` agent goes through the following states: + +- request-received +- completed + +The state transition table for the `server` is: + +| State / Events | Receive Request | Send Response or Problem Report | +| ---------------- | -------------------------------------- | ------------------------------- | +| *Start* | Transition to
**request-received** | | +| request-received | | Transition to
**complete** | +| completed | | | + +### Messages + +The following are the messages in the DRPC protocol. The `response` message +handles all positive responses, so the `ack` ([RFC 0015 ACKs]) message is +**NOT** adopted by this protocol. The [RFC 0035 Report Problem] is adopted by +this protocol in the event that a `request` is not recognizable as a [JSON-RPC] +message and as such, a [JSON-RPC] response message cannot be created. See the +details below in the [Problem Report Message](#problem-report-message) section. + +[RFC 0015 ACKs]: ../features/0015-acks/README.md) +[RFC 0035 Report Problem]: ../features/0035-report-problem/README.md + +#### Request Message + +The `request` message is sent by the `client` to initiate the protocol. The +message contains the [JSON-RPC] information necessary for the `server` to +process the request, prepare the response, and send the response message back to +the `client`. It is assumed the `client` knows what types of requests the +`server` is prepared to receive and process. If the `server` does not know how +to process the error, [JSON-RPC] has a standard response, outlined in the +[response message](#response-message) section below. How the `client` and +`server` coordinate that understanding is out of scope of this protocol. + +The `request` message uses the same JSON items as [JSON-RPC], skipping the +`id` in favor of the existing DIDComm `@id` and thread handling. + +```jsonc + { + "@type": "https://didcomm.org/drpc/1.0/request", + "@id": "2a0ec6db-471d-42ed-84ee-f9544db9da4b", + "request" : {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} + } +``` + +The items in the message are as follows: + +- `@type` -- required, must be as above +- `@id` -- required, must be as defined in [RFC 0005 DIDComm] +- `request` -- **required**, an item containing a [JSON-RPC] request JSON structure. + - `request` **MUST** be either a single [JSON-RPC] request, or an array of [JSON-RPC] requests. + - Each [JSON-RPC] request **MUST** have the `jsonrpc` and `method` items. + - Each [JSON-RPC] request **MAY** have the `params` and `id` items. + - See the details below about the handling of `notification` [JSON-RPC] requests, requests where the `id` field is omitted. + - See the [JSON-RPC] specification for details about the `jsonrpc`, `method`, `params` and `id` JSON items. + +Per the [JSON-RPC] specification, if the `id` field of a [JSON-RPC] request is omitted, the `server` should not respond. In this DRPC DIDComm protocol, the `server` is always expected to send a `response`, but **MUST NOT** include +a [JSON-RPC] response for any [JSON-RPC] request for which the `id` is omitted. This is covered further +in the [response message](#response-message) section (below). + +#### Response Message + +A `response` message is sent by the `server` to following the +processing of the request to convey the output of the processing to the +`client`. As with the `request` the format mostly exactly that of a +[JSON-RPC] response. + +If the `request` is unrecognizable as a [JSON-RPC] message such that a +[JSON-RPC] message cannot be generated, the `server` SHOULD send a [RFC 0035 +Report Problem] message to the `client`. + +It is assumed the `client` understands what the contents of the +`response` message means in the context of the protocol instance. How the +`client` and `server` coordinate that understanding is out of scope of this +protocol. + +```jsonc + + { + "@type": "https://didcomm.org/drpc/1.0/response", + "@id": "63d6f6cf-b723-4eaf-874b-ae13f3e3e5c5", + "response": {"jsonrpc": "2.0", "result": 19, "id": 1} + } +``` + +The items in the message are as follows: + +- `@type` -- required, must be as above +- `@id` -- required, must be as defined in [RFC 0005 DIDComm] +- `response` -- **required**, an item containing a [JSON-RPC] response JSON structure. + - `response` **MUST** be either single (possibly empty) [JSON-RPC] response, + or an array of [JSON-RPC] responses. + - If all of the [JSON-RPC] requests in the `request` message are + *notifications* (e.g., the `id` item is omitted), the DIDComm `response` + message **MUST** be sent back with the value: `"response" : {}`. + - Each [JSON-RPC] response **MUST** have the `jsonrpc` and `id` items, and either a `result` or `error` item. + - See the [JSON-RPC] specification for details about the `jsonrpc`, `id`, `result` and `error` JSON items. + +As with all DIDComm messages that are not the first in a protocol instance, a +`~thread` decorator **MUST** be included in the `response` message. + +The special handling of the "all [JSON-RPC] requests are notifications" +described above is to simplify the DRPC handling to know when a DRPC protocol +instance is complete. If a `response` message is not always required, the DRPC +handler would have to inspect the `request` message to look for `id`s to +determine when the protocol completes. + +If the `server` does not understand how to process a given [JSON-RPC] request, a +`response` error **SHOULD** be returned (as per the [JSON-RPC] specification) with: + +- `error.code` value `-32601`, +- `error.message` set to `Method not found`, and +- no `error.data` item. + +#### Problem Report Message + +A [RFC 0035 Report Problem] message **SHOULD** be sent by the `server` instead +of a `response` message only if the `request` is unrecognizable as a [JSON-RPC] message. +An [JSON-RPC] errors **MUST** be provided to the `client` by the `server` via the +`response` message, not a `problem-report`. The `client` **MUST NOT** +respond to a `response` message, even if the `response` message is not a valid +[JSON-RPC] response. This is because once the `server` sends the `response`, the +protocol is in the `completed` state (from the `server`'s perspective) and so +is subject to deletion. As such, a follow up `problem-report` message would have +an invalid `thid` (thread ID) and (at best) be thrown away by the `server`. + +### Constraints + +The primary constraint with this protocol is that the two parties using the +protocol must understand one another--what [JSON-RPC] request(s) to use, what +parameters to provide, how to process the those requests, what the `response` +means, and so on. It is not a protocol to be used between arbitrary parties, but +rather one where the parties have knowledge outside of DIDComm of one another +and their mutual capabilities. + +On the other hand, that constraint enables great flexibility for explicitly +collaborating agents (such as a mobile wallet and the agent of its manufacturer) +to accomplish request-response transactions over DIDComm without +needing to define additional DIDComm protocols. More complex interactions can be +accomplished by carrying out a sequence of DRPC protocol instances between +agents. + +The flexibility the DRPC protocol allows for experimenting with specific +interactions between agents that could later evolve into formal DIDComm "fit for +purpose" protocols. + +## Reference + +### Codes Catalog + +A [JSON-RPC] request codes catalog *could* be developed over time and be +included in this part of the RFC. This might an intermediate step in transitioning +a given interaction implemented using DRPC into formally specified interaction. +On the other hand, simply defining a full DIDComm protocol will often be a far +better approach. + +At this time, there are no codes to be cataloged. + +## Drawbacks + +Anything that can be done by using the DRPC protocol can be accomplished by a +formally defined protocol specific to the task to be accomplished. The advantage +of the DRPC protocol is that pairs of agent instances that are explicitly +collaborating can use this protocol without having to first define a +task-specific protocol. + +## Rationale and alternatives + +We considered not supporting the *notification* and *batch* forms of the +[JSON-RPC] specification, and decided it made sense to allow for the full +support of the [JSON-RPC] specification, including requests of those forms. That +said, we also found that the concept of **not** having a DRPC `response` message +in some (likely, rare) cases based on the contents of the `request` JSON item +(e.g., when all of the `id`s are omitted from the [JSON-RPC] requests) would +unnecessarily complicate the DIDComm protocol instance handling about when it is +complete. As a result, a DRPC `response` message is always required. + +This design builds on the experience of implementations of this kind of feature +using [RFC 0095 Basic Message] and [RFC 0335 HTTP Over DIDComm]. This design +tries to build off the learnings gained from both of those implementations. + +Based on feedback to an original version of the RFC, we looked as well at +using [gRPC] as the core of this protocol, versus [JSON-RPC]. Our assessment +was that [gRPC] was a much heavier weight mechanism that required more effort +between parties to define and implement what will often be a very simple +request-response transaction -- at the level of defining a DIDComm protocol. + +[gRPC]: https://grpc.io/ + +The use of `params` and leaving the content and semantics of the params up to +the `client` and `server` means that they can define the appropriate handling of +the parameters. This eliminates the need for the protocol to define, for +example, that some data needs to be Base64 encoding for transmission, or if some +values need to be cryptographically signed. Such details are left to the +participants and how they are using the protocol. + +## Prior art + +This protocol has similar goals to the [RFC 0335 HTTP Over DIDComm] protocol, +but takes a lighter weight, more flexible approach. We expect that implementing +HTTP over DIDComm using this protocol will be as easy as using [RFC 0335 HTTP +Over DIDComm], where the [JSON-RPC] request's `params` data structure holds the +`headers` and `body` elements for the HTTP request. On the other hand, using the +explicit [RFC 0335 HTTP Over DIDComm] is might be a better choice if it is +available and exactly what is needed. + +[RFC 0335 HTTP Over DIDComm]: /features/0335-http-over-didcomm/README.md + +One of the example use cases for this protocol has been implemented by "hijacking" the +[RFC 0095 Basic Message] protocol to carry out the needed request/response actions. This +approach is less than ideal in that: + +- That is not the intended use of [RFC 0095 Basic Message], which is to send a + basic, human consumable message to the other agent. +- The request method and parameters have to be encoded into the basic message. +- The [RFC 0095 Basic Message] protocol is a single message protocols, so each + request-response interaction requires two instances of the protocol, and for + the controllers to manage connecting the interactions together. + +[RFC 0095 Basic Message]: /features/0095-basic-message/README.md + +## Unresolved questions + +- Should we include the idea of a `request` having a goal code ([RFC 0519 Goal Codes])? + +[RFC 0519 Goal Codes]: /concepts/0519-goal-codes/README.md + +## 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. + +*Implementation Notes* [may need to include a link to test results](README.md). + +Name / Link | Implementation Notes +--- | --- + | diff --git a/features/0809-w3c-data-integrity-credential-attachment/README.md b/features/0809-w3c-data-integrity-credential-attachment/README.md new file mode 100644 index 000000000..3946cdd32 --- /dev/null +++ b/features/0809-w3c-data-integrity-credential-attachment/README.md @@ -0,0 +1,321 @@ +# Aries RFC 0809: W3C Verifiable Credential Data Integrity Attachment format for requesting and issuing credentials + +- Authors: Timo Glastra (Animo Solutions) +- Status: [PROPOSED](/README.md#proposed) +- Since: 2024-01-10 +- Status Note: +- Supersedes: [Aries RFC 0593: JSON-LD Credential Attachment](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md) +- Start Date: 2023-12-18 +- Tags: [feature](/tags.md#feature), [protocol](/tags.md#protocol), [credentials](/tags.md#credentials), [test-anomaly](/tags.md#test-anomaly) + +## Summary + +This RFC registers an attachment format for use in the [issue-credential V2](../0453-issue-credential-v2/README.md) protocol based on W3C Verifiable Credentials with [Data Integrity Proofs](https://www.w3.org/TR/vc-data-integrity/) from the [VC Data Model](https://www.w3.org/TR/vc-data-model/#linked-data-proofs). + +## Motivation + +The Issue Credential protocol needs an attachment format to be able to exchange W3C verifiable credentials. It is desirable to make use of specifications developed in an open standards body, such as the [Credential Manifest](https://identity.foundation/credential-manifest/) for which the attachment format is described in [RFC 0511: Credential-Manifest Attachment format](../0511-dif-cred-manifest-attach/README.md). However, the _Credential Manifest_ is not finished and ready yet, and therefore there is a need to bridge the gap between standards. + +## Tutorial + +Complete examples of messages are provided in the [reference section](#reference). + +## Reference + +### Credential Offer Attachment Format + +Format identifier: `didcomm/w3c-di-vc-offer@v0.1` + +```json +{ + "data_model_versions_supported": ["1.1", "2.0"], + "binding_required": true, + "binding_method": { + "anoncreds_link_secret": { + "nonce": "1234", + "cred_def_id": "did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition", + "key_correctness_proof": "" + }, + "didcomm_signed_attachment": { + "algs_supported": ["EdDSA"], + "did_methods_supported": ["key", "web"], + "nonce": "1234" + } + }, + "credential": { + "@context": [ + "https://www.w3.org/2018/credentials/v1", + "https://w3id.org/security/data-integrity/v2", + { + "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#" + } + ], + "type": ["VerifiableCredential"], + "issuer": "did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT", + "issuanceDate": "2024-01-10T04:44:29.563418Z", + "credentialSubject": { + "height": 175, + "age": 28, + "name": "Alex", + "sex": "male" + } + } +} +``` + +- `data_model_versions_supported` - Required. List of strings indicating the supported VC Data Model versions. The list MUST contain at least one value. The values MUST be a valid data model version. Current supported values include `1.1` and `2.0`. +- `binding_required` - Optional. Boolean indicating whether the credential MUST be bound to the holder. If omitted, the credential is not required to be bound to the holder. If set to `true`, the credential MUST be bound to the holder using at least one of the binding methods defined in `binding_method`. +- `binding_method` - Required if `binding_required` is true. Object containing key-value pairs of binding methods supported by the issuer to bind the credential to a holder. If the value is omitted, this indicates the issuer does not support any binding methods for issuance of the credential. See [Binding Methods](#binding-methods) for a registry of default binding methods supported as part of this RFC. +- `credential` - Required. The credential to be issued. The credential MUST be compliant with the **first** `data_model_versions_supported` entry version of VC Data Model, except for the omission of a set required keys that may only be known at the time of issuance. See [Credential Offer Exceptions](#credential-offer-exceptions) for a list of exceptions. The credential MUST NOT contain any proofs. Some properties MAY be omitted if they will only be available at time of issuance, such as `issuanceDate`, `issuer`, `credentialSubject.id`, `credentialStatus`, `credentialStatus.id`. + +#### Credential Offer Exceptions + +To allow for validation of the `credential` according to the corresponding VC Data Model version, the `credential` in the offer MUST be conformant to the corresponding VC Data Model version, except for the exceptions listed below. This still allows the credential to be validated, knowing which deviations are possible. + +The list of exception is as follows: + +- `issuanceDate` (v1.1) or `validFrom` (v2.0) can be omitted, or set to a placeholder value. +- `issuer` (or `issuer.id` if issuer is an object) can be omitted +- `credentialSubject.id` can be omitted +- `credentialStatus` + - Either the whole `credentialStatus` can be omitted + - OR the `credentialStatus.type` can be present, but other required fields that are dynamic can be omitted (such as the `statusListIndex` and `statusListCredential` in case of [Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/)) + +### Credential Request Attachment Format + +Format identifier: `didcomm/w3c-di-vc-request@v0.1` + +This format is used to request a verifiable credential. The JSON structure might look like this: + +```json +{ + "data_model_version": "2.0", + "binding_proof": { + "anoncreds_link_secret": { + "entropy": "", + "cred_def_id": "did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition", + "blinded_ms": {}, + "blinded_ms_corectness_proof": {}, + "nonce": "" + }, + "didcomm_signed_attachment": { + "attachment_id": "<@id of the attachment>" + } + } +} +``` + +- `data_model_version` - Required. The data model version of the credential to be issued. The value MUST be a valid data model version and match one of the values from the `data_model_versions_supported` offer. +- `binding_proof` - Required if `binding_required` is `true` in the offer. Object containing key-value pairs of proofs for the binding to the holder. The keys MUST match keys of the `binding_method` object from the offer. See [Binding Methods](#binding-methods) for a registry of default binding methods supported as part of this RFC. + +### Credential Attachment Format + +Format identifier: `didcomm/w3c-di-vc@v0.1` + +This format is used to transmit a verifiable credential. The JSON structure might look like this: + +```json +{ + "credential": { + // vc with proof object or array + } +} +``` + +- `credential` - The signed credential. MUST be a valid verifiable credential object with one or more proofs and MUST conform to VC Data Model version as defined in the `data_model_version` of the request. + +It is up to the issuer to the pick an appropriate cryptographic suite to sign the credential. The issuer may use the cryptographic binding material provided by the holder to select the cryptographic suite. For example, when the `anoncreds_link_secret` binding method is used, the issuer should use an `DataIntegrityProof` with the `anoncredsvc-2023` cryptographic suite. When a holder provides a signed attachment as part of the binding proof using the `EdDSA` JWA alg, the issuer could use a `DateIntegrityProof` with the `eddsa-rdfc-2022` cryptographic suite. However, it is not required for the cryptographic suite used for the signature on the credential to be in any way related to the cryptographic suite used for the binding proof, unless the binding method explicitly requires this (for example the `anoncreds_link_secret` binding method). + +A complete [`issue-credential` message from the Issue Credential protocol 2.0](../0453-issue-credential-v2/README.md#issue-credential) might look like this: + +```json +{ + "@id": "284d3996-ba85-45d9-964b-9fd5805517b6", + "@type": "https://didcomm.org/issue-credential/2.0/issue-credential", + "comment": "", + "formats": [ + { + "attach_id": "5b38af88-d36f-4f77-bb7a-2f04ab806eb8", + "format": "didcomm/w3c-di-vc@v0.1" + } + ], + "credentials~attach": [ + { + "@id": "5b38af88-d36f-4f77-bb7a-2f04ab806eb8", + "mime-type": "application/json", + "data": { + "base64": "ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=" + } + } + ] +} +``` + +### Binding Methods + +The attachment format supports different methods to bind the credential to the receiver of the credential. In the offer message the issuer can indicate which binding methods are supported in the `binding_methods` object. Each key represents the id of the supported binding method. + +This section defines a set of binding methods supported by this attachment format, but other binding methods may be used. Based on the binding method, the request needs to include a `binding_proof` object where the key matches the key of the binding method from the offer. + +#### AnonCreds Link Secret + +Identifier: `anoncreds_link_secret` + +This binding method is intended to be used in combination with a credential containing an AnonCreds proof. + +##### Binding Method in Offer + +The structure of the binding method in the offer MUST match the structure of the [Credential Offer](https://hyperledger.github.io/anoncreds-spec/#credential-offer) as defiend in the AonCreds specification, with the exclusion of the `schema_id` key. + +```jsonc +{ + "nonce": "1234", + "cred_def_id": "did:key:z6MkwXG2WjeQnNxSoynSGYU8V9j3QzP3JSqhdmkHc6SaVWoT/credential-definition", + "key_correctness_proof": { + /* key correctness proof object */ + } +} +``` + +##### Binding Proof in Request + +The structure of the binding proof in the request MUST match the structure of the [Credential Request](https://hyperledger.github.io/anoncreds-spec/#credential-request) as defined in the AnonCreds specification. + +```jsonc +{ + "anoncreds_link_secret": { + "entropy": "", + "blinded_ms": { + /* blinded ms object */ + }, + "blinded_ms_corectness_proof": { + /* blinded ms correctness proof object */ + }, + "nonce": "" + } +} +``` + +##### Binding in Credential + +The issued credential should be bound to the holder by including the blinded link secret in the credential as defined in the [Issue Credential section](https://hyperledger.github.io/anoncreds-spec/#issue-credential) of the AnonCreds specification. Credential bound using the AnonCreds link secret binding method MUST contain an proof with `proof.type` value of `DataIntegrityProof` and `cryptosuite` value of `anoncredsvc-2023`, and conform to the [AnonCreds W3C Verifiable Credential Representation](https://hyperledger.github.io/anoncreds-spec/#w3c-verifiable-credentials-representation). + +#### DIDComm Signed Attachment + +Identifier: `didcomm_signed_attachment` + +This binding method leverages [DIDComm signed attachments](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#signing-attachments) to bind a credential to a specific key and/or identifier. + +##### Binding Method in Offer + +```jsonc +{ + "didcomm_signed_attachment": { + "algs_supported": ["EdDSA"], + "did_methods_supported": ["key"], + "nonce": "b19439b0-4dc9-4c28-b796-99d17034fb5c" + } +} +``` + +- `algs_supported` - Required. List of strings indicating the Json Web Algorithms supported by the issuer for verifying the signed attachment. The list MUST contain at least one value. The values MUST be a valid algorithm identifier as defined in the [JSON Web Signature and Encryption Algorithms](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) registry. +- `did_methods_supported` - Required. List of strings indicating which did methods are supported by the issuer for binding the credential to the holder. The list MUST contain at least one value. Values should ONLY include the method identifier of the did method. Examples values include `key` or `web`. +- `nonce` - Required. Nonce to be used in the request to prevent replay attacks of the signed attachment. + +##### Binding Proof in Request + +The binding proof in the request points to an appended attachment containing the signed attachment. + +```json +{ + "didcomm_signed_attachment": { + "attachment_id": "<@id of the attachment>" + } +} +``` + +- `attachment_id` - The id of the appended attachment included in the request message that contains the signed attachment. + +###### Signed Attachment Content + +The attachment MUST be signed by including a signature in the `jws` field of the attachment. The data MUST be a JSON document encoded in the `base64` field of the attachment. The structure of the signed attachment is described below. + +**JWS Payload** + +```json +{ + "nonce": "", +} +``` + +- `nonce` - Required. The `nonce` from the `didcomm_signed_attachment` object within `binding_method` from the credential offer + +**Protected Header** + +```json +{ + "alg": "EdDSA", + "kid": "did:key:z6MkkwiqX7BvkBbi37aNx2vJkCEYSKgHd2Jcgh4AUhi4YY1u#z6MkkwiqX7BvkBbi37aNx2vJkCEYSKgHd2Jcgh4AUhi4YY1u" +} +``` + +- `alg`: REQUIRED. A digital signature algorithm identifier such as per IANA "JSON Web Signature and Encryption Algorithms" registry. MUST NOT be none or an identifier for a symmetric algorithm (MAC). MUST match one of the `algs_supported` entries from the offer `binding_method` object. +- `kid`: REQUIRED. JOSE Header containing the DID URL pointing to a specific key in a did document. The did method of the DID URL MUST match with one of the `did_methods_supported` from the offer `binding_method` object. + +A signed binding request attachment appended to a request message might look like this: + +```json +{ + "@id": "284d3996-ba85-45d9-964b-9fd5805517b6", + "@type": "https://didcomm.org/issue-credential/2.0/request-credential", + "comment": "", + "formats": [ + { + "attach_id": "5b38af88-d36f-4f77-bb7a-2f04ab806eb8", + "format": "didcomm/w3c-di-vc-request@v0.1" + } + ], + "~attach": [ + { + "@id": "123", + "mime-type": "application/json", + "data": { + "base64": "", + "jws": { + "protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)", + "signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)" + } + } + } + ], + "credentials~attach": [ + { + "@id": "5b38af88-d36f-4f77-bb7a-2f04ab806eb8", + "mime-type": "application/json", + "data": { + "base64": "ewogICAgICAgICAgIkBjb250ZXogWwogICAgICAg...(clipped)...RNVmR0SXFXZhWXgySkJBIgAgfQogICAgICAgIH0=" + } + } + ] +} +``` + +##### Binding in Credential + +The issued credential should be bound to the holder by including the did in the credential as `credentialSubject.id` or `holder`. + +## Drawbacks + +- While it has a similar setup and structure compared to OpenID for Verifiable Credential Issuance, this attachment format only focuses on issuance of W3C Verifiable Credentials. Therefore another (but probably quite similar) attachment format needs to be defined to support issuance of non-W3C VCs +- There is currently no way for an issuer or holder to indicate which cryptographic suites they support for the signature of the credential. Currently it's at the discretion of the issuer to decide which cryptographic suite to use. In a future (minor) version we can add an optional way for a) the issuer to indicate which cryptographic suites they support, and b) the holder to indicate which cryptographic suites they support. +- There is currently no attachment format defined for a credential proposal. This makes it impossible for a holder to initiate the issuance of a credential using this attachment format. In a future (minor) version the proposal attachment format can be added. + +## Rationale and alternatives + +[RFC 0593: JSON-LD Credential Attachment](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md), [W3C VC API](https://w3c-ccg.github.io/vc-api/) allows issuance of credentials using only linked data signatures, while [RFC 0592: Indy Attachment](https://github.com/hyperledger/aries-rfcs/blob/main/features/0592-indy-attachments/README.md) supports issuance of AnonCreds credentials. This attachment format aims to support issuance of both previous attachment formats (while for AnonCreds it now being in the W3C model), as well as supporting additional features such as issuance W3C JWT VCs, credentials with multiple proofs, and cryptographic binding of the credential to the holder. + +## Prior art + +The attachment format in this RFC is heavily inspired by [RFC 0593: JSON-LD Credential Attachment](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md), [W3C VC API](https://w3c-ccg.github.io/vc-api/) and [OpenID for Verifiable Credential Issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html). + +## Unresolved questions