From 9c481a0db93fb9969529c62027276c8240955c9f Mon Sep 17 00:00:00 2001 From: James Ebert Date: Tue, 4 Jun 2024 13:09:10 -0700 Subject: [PATCH 1/3] fix: incorrect json formatting Signed-off-by: James Ebert --- features/0056-service-decorator/README.md | 12 +- features/0212-pickup/README.md | 85 ++++++---- features/0213-transfer-policy/README.md | 68 ++++---- features/0685-pickup-v2/README.md | 18 +-- .../0728-device-binding-attachments/README.md | 145 +++++++++--------- 5 files changed, 177 insertions(+), 151 deletions(-) diff --git a/features/0056-service-decorator/README.md b/features/0056-service-decorator/README.md index 04727a7ee..b7e5de431 100644 --- a/features/0056-service-decorator/README.md +++ b/features/0056-service-decorator/README.md @@ -23,7 +23,7 @@ The `~service` decorator on a message contains the service definition that you m Usage looks like this, with the contents defined the [Service Endpoint section of the DID Spec](https://w3c-ccg.github.io/did-spec/#service-endpoints): -```json= +```json { "@type": "somemessagetype", "~service": { @@ -34,11 +34,9 @@ Usage looks like this, with the contents defined the [Service Endpoint section o } ``` - - ## Reference -The contents of the `~service` decorator are defined by the [Service Endpoint section of the DID Spec](https://w3c-ccg.github.io/did-spec/#service-endpoints). +The contents of the `~service` decorator are defined by the [Service Endpoint section of the DID Spec](https://w3c-ccg.github.io/did-spec/#service-endpoints). The decorator should not be used when the message recipient already has a service endpoint. @@ -65,6 +63,6 @@ The Connect Protocol had previously included this same information as an attribu The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation. -Name / Link | Implementation Notes ---- | --- - | | +| Name / Link | Implementation Notes | +| ----------- | -------------------- | +| | diff --git a/features/0212-pickup/README.md b/features/0212-pickup/README.md index eccaa3308..3c8fd18a0 100644 --- a/features/0212-pickup/README.md +++ b/features/0212-pickup/README.md @@ -1,4 +1,5 @@ # 0212: Pickup Protocol + - Authors: [Sam Curren](mailto:telegramsam@gmail.com) - Status: [PROPOSED](/README.md#proposed) - Since: 2019-09-03 @@ -32,41 +33,52 @@ batch retrieval can be executed when many messages ... ## Reference ### StatusRequest + Sent by the _recipient_ to the _message_holder_ to request a `status` message. -```json= + +```json { - "@id": "123456781", - "@type": "https://didcomm.org/messagepickup/1.0/status-request" + "@id": "123456781", + "@type": "https://didcomm.org/messagepickup/1.0/status-request" } ``` + ### Status + Status details about pending messages -```json= + +```json { - "@id": "123456781", - "@type": "https://didcomm.org/messagepickup/1.0/status", - "message_count": 7, - "duration_waited": 3600, - "last_added_time": "2019-05-01 12:00:00Z", - "last_delivered_time": "2019-05-01 12:00:01Z", - "last_removed_time": "2019-05-01 12:00:01Z", - "total_size": 8096 + "@id": "123456781", + "@type": "https://didcomm.org/messagepickup/1.0/status", + "message_count": 7, + "duration_waited": 3600, + "last_added_time": "2019-05-01 12:00:00Z", + "last_delivered_time": "2019-05-01 12:00:01Z", + "last_removed_time": "2019-05-01 12:00:01Z", + "total_size": 8096 } ``` + `message_count` is the only required attribute. The others may be present if offered by the _message_holder_. + ### Batch Pickup + A request to have multiple waiting messages sent inside a `batch` message. -```json= + +```json { - "@id": "123456781", - "@type": "https://didcomm.org/messagepickup/1.0/batch-pickup", - "batch_size": 10 + "@id": "123456781", + "@type": "https://didcomm.org/messagepickup/1.0/batch-pickup", + "batch_size": 10 } ``` ### Batch + A message that contains multiple waiting messages. -```json= + +```json { "@id": "123456781", "@type": "https://didcomm.org/messagepickup/1.0/batch", @@ -87,22 +99,29 @@ A message that contains multiple waiting messages. ] } ``` + ### Message Query With Message Id List + A request to read single or multiple messages with a message message id array. -```json= + +```json { - "@id": "123456781", - "@type": "https://didcomm.org/messagepickup/1.0/list-pickup", - "message_ids": [ - "06ca25f6-d3c5-48ac-8eee-1a9e29120c31", - "344a51cf-379f-40ab-ab2c-711dab3f53a9a" - ] + "@id": "123456781", + "@type": "https://didcomm.org/messagepickup/1.0/list-pickup", + "message_ids": [ + "06ca25f6-d3c5-48ac-8eee-1a9e29120c31", + "344a51cf-379f-40ab-ab2c-711dab3f53a9a" + ] } ``` + `message_ids` message id array for picking up messages. Any message id in `message_ids` could be delivered via several ways to the recipient (Push notification or with an envoloped message). + ### Message List Query Response + A response to query with message id list. -```json= + +```json { "@type": "https://didcomm.org/messagepickup/1.0/list-response", "messages~attach": [ @@ -121,16 +140,18 @@ A response to query with message id list. ] } ``` + ### Noop + Used to receive another message implicitly. This message has no expected behavior when received. -```json= + +```json { - "@id": "123456781", - "@type": "https://didcomm.org/messagepickup/1.0/noop" + "@id": "123456781", + "@type": "https://didcomm.org/messagepickup/1.0/noop" } ``` - ## Prior art Concepts here borrow heavily from a [document](https://hackmd.io/@8VtAqKThQ6mKa9T7JgzIaw/SJw9Ead2N?type=view) written by Andrew Whitehead of BCGov. @@ -143,6 +164,6 @@ Concepts here borrow heavily from a [document](https://hackmd.io/@8VtAqKThQ6mKa9 The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation. -Name / Link | Implementation Notes ---- | --- - | | +| Name / Link | Implementation Notes | +| ----------- | -------------------- | +| | diff --git a/features/0213-transfer-policy/README.md b/features/0213-transfer-policy/README.md index 2e36dd944..6e440b147 100644 --- a/features/0213-transfer-policy/README.md +++ b/features/0213-transfer-policy/README.md @@ -1,4 +1,5 @@ # 0213: Transfer Policy Protocol + - Authors: [Sam Curren](mailto:telegramsam@gmail.com) - Status: [PROPOSED](/README.md#proposed) - Since: 2019-09-03 @@ -24,65 +25,70 @@ Explicit Policy Enables clear expectations. ## Reference ### Policy Publish + Used to share current policy by policy holder. This can be sent unsolicited or in response to a `policy_share_request`. -```json= + +```json { - "@id": "123456781", - "@type": "https://didcomm.org/transferpolicy/1.0/policy", - "queue_max_duration": 86400, - "message_count_limit": 1000, - "message_size_limit": 65536, - "queue_size_limit": 65536000, - "pickup_allowed": true, - "delivery_retry_count_limit":5, - "delivery_retry_count_seconds":86400, - "delivery_retry_backoff": "exponential" + "@id": "123456781", + "@type": "https://didcomm.org/transferpolicy/1.0/policy", + "queue_max_duration": 86400, + "message_count_limit": 1000, + "message_size_limit": 65536, + "queue_size_limit": 65536000, + "pickup_allowed": true, + "delivery_retry_count_limit": 5, + "delivery_retry_count_seconds": 86400, + "delivery_retry_backoff": "exponential" } ``` + ### Policy Share Request + Used to ask for a `policy` message to be sent. -```json= +```json { - "@id": "123456781", - "@type": "https://didcomm.org/transferpolicy/1.0/policy_share_request" + "@id": "123456781", + "@type": "https://didcomm.org/transferpolicy/1.0/policy_share_request" } ``` ### Policy Change Request -Sent to request a policy change. The expected response is a `policy` message. -```json= +Sent to request a policy change. The expected response is a `policy` message. +```json { - "@id": "123456781", - "@type": "https://didcomm.org/transferpolicy/1.0/policy_change_request", - "queue_max_duration": 86400, - "message_count_limit": 1000, - "message_size_limit": 65536, - "queue_size_limit": 65536000, - "pickup_allowed": true, - "delivery_retry_count_limit":5, - "delivery_retry_count_seconds":86400, - "delivery_retry_backoff": "exponential" + "@id": "123456781", + "@type": "https://didcomm.org/transferpolicy/1.0/policy_change_request", + "queue_max_duration": 86400, + "message_count_limit": 1000, + "message_size_limit": 65536, + "queue_size_limit": 65536000, + "pickup_allowed": true, + "delivery_retry_count_limit": 5, + "delivery_retry_count_seconds": 86400, + "delivery_retry_backoff": "exponential" } ``` -Only attributes that you desire to change need to be included. +Only attributes that you desire to change need to be included. ## Prior art + Concepts here borrow heavily from a [document](https://hackmd.io/@8VtAqKThQ6mKa9T7JgzIaw/SJw9Ead2N?type=view) written by Andrew Whitehead of BCGov. ## Unresolved questions - Is the attribute list too extensive for a first pass? - Which policy attributes should be required? Which optional? - + ## Implementations The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation. -Name / Link | Implementation Notes ---- | --- - | | +| Name / Link | Implementation Notes | +| ----------- | -------------------- | +| | diff --git a/features/0685-pickup-v2/README.md b/features/0685-pickup-v2/README.md index 58912b2bb..4e7948c83 100644 --- a/features/0685-pickup-v2/README.md +++ b/features/0685-pickup-v2/README.md @@ -45,7 +45,7 @@ rather than being pushed to the queue. See [Live Mode](#live-mode) for more deta Each message sent MUST use the `~transport` decorator as follows, which has been adopted from [RFC 0092 transport return route](/features/0092-transport-return-route/README.md) protocol. This has been omitted from the examples for brevity. -```json= +```json "~transport": { "return_route": "all" } @@ -58,7 +58,7 @@ Each message sent MUST use the `~transport` decorator as follows, which has been Sent by the _Recipient_ to the _Mediator_ to request a `status` message. #### Example: -```json= +```json { "@id": "123456781", "@type": "https://didcomm.org/messagepickup/2.0/status-request", @@ -74,7 +74,7 @@ Status details about waiting messages. #### Example: -```json= +```json { "@id": "123456781", "@type": "https://didcomm.org/messagepickup/2.0/status", @@ -110,7 +110,7 @@ A request from the _Recipient_ to the _Mediator_ to have pending messages delive #### Examples: -```json= +```json { "@id": "123456781", "@type": "https://didcomm.org/messagepickup/2.0/delivery-request", @@ -119,7 +119,7 @@ A request from the _Recipient_ to the _Mediator_ to have pending messages delive } ``` -```json= +```json { "@type": "https://didcomm.org/messagepickup/2.0/delivery-request", "limit": 1 @@ -143,7 +143,7 @@ The ONLY valid type of attachment for this message is a DIDComm Message in encry The `recipient_key` attribute is only included when responding to a `delivery-request` message that indicates a `recipient_key`. -```json= +```json { "@id": "123456781", "~thread": { @@ -168,7 +168,7 @@ which messages are safe to clear from the queue. #### Example: -```json= +```json { "@type": "https://didcomm.org/messagepickup/2.0/messages-received", "message_id_list": ["123","456"] @@ -201,7 +201,7 @@ Live Mode is changed with a `live-delivery-change` message. #### Example: -```json= +```json { "@type": "https://didcomm.org/messagepickup/2.0/live-delivery-change", "live_delivery": true @@ -212,7 +212,7 @@ Upon receiving the `live_delivery_change` message, the _Mediator_ MUST respond w If sent with `live_delivery` set to `true` on a connection incapable of live delivery, a `problem_report` SHOULD be sent as follows: -```json= +```json { "@type": "https://didcomm.org/notification/1.0/problem-report", "~thread": { diff --git a/features/0728-device-binding-attachments/README.md b/features/0728-device-binding-attachments/README.md index a620e47d9..e127cba1e 100644 --- a/features/0728-device-binding-attachments/README.md +++ b/features/0728-device-binding-attachments/README.md @@ -1,8 +1,9 @@ # Aries RFC 0728 : Device Binding Attachments + - Authors: [Paul Bastian](mailto:paul.bastian@bdr.de), [Sebastian Bickerle](mailto:sebastian.bickerle@main-incubator.com) - Status: [PROPOSED](/README.md#proposed) - Since: 2022-04-07 -- Status Note: This is an initial draft +- Status Note: This is an initial draft - Start Date: 2022-01-01 - Tags: [feature](/tags.md#feature) @@ -27,17 +28,18 @@ To proof the control of a hardware bound key the holder must answer a challenge The following challenge object must be provided by the verifier. #### device-binding-challenge -```json= + +```json { - "@type": "https://didcomm.org/device-binding/%ver/device-binding-challenge", - "@id": "", - "nonce": "", // recommend at least 128-bit unsigned integer - "requests": [ - { - "id": "libindy-request-presentation-0", - "path": "$.requested_attributes.attr2_referent.names.hardwareDid", - } - ] + "@type": "https://didcomm.org/device-binding/%ver/device-binding-challenge", + "@id": "", + "nonce": "", // recommend at least 128-bit unsigned integer + "requests": [ + { + "id": "libindy-request-presentation-0", + "path": "$.requested_attributes.attr2_referent.names.hardwareDid" + } + ] } ``` @@ -45,9 +47,8 @@ Description of attributes: - `nonce` -- a nonce which has to be signed by the holder to proof control - `requests` -- an array of referenced presentation requests - - `id` -- reference to an attached presentation request of `request-presentation` message (e.g. libindy request) - - `path` -- JsonPath to a requested attribute which represents a public key of a hardware bound key pair - represented as did:key - + - `id` -- reference to an attached presentation request of `request-presentation` message (e.g. libindy request) + - `path` -- JsonPath to a requested attribute which represents a public key of a hardware bound key pair - represented as did:key The `device-binding-challenge` must be attached to the `request-presentations~attach` array of the `request-presentation` message defined by [RFC-0037](https://github.com/hyperledger/aries-rfcs/blob/main/features/0037-present-proof/README.md#request-presentation) and [RFC-0454](https://github.com/hyperledger/aries-rfcs/tree/main/features/0454-present-proof-v2#request-presentation). @@ -56,7 +57,8 @@ The `device-binding-challenge` must be attached to the `request-presentations~at The following represents a request-presentation message with an attached libindy presentation request and a corresponding device-binding-challenge. **Present Proof v1** -```json= + +```json { "@type": "https://didcomm.org/present-proof/1.0/request-presentation", "@id": "", @@ -84,7 +86,7 @@ The following represents a request-presentation message with an attached libindy **Present Proof v2** -```json= +```json { "@type": "https://didcomm.org/present-proof/2.0/request-presentation", "@id": "", @@ -119,30 +121,30 @@ The following represents a request-presentation message with an attached libindy } ``` - ### Response The following response must be generated by the holder of the VC. #### device-binding-reponse -```json= + +```json { - "@type": "https://didcomm.org/device-binding/%ver/device-binding-response", - "@id": "", - "proofs" : [ - { - "id": "libindy-presentation-0", - "path": "$.requested_proof.revealed_attrs.attr1_referent.raw" - } - ] + "@type": "https://didcomm.org/device-binding/%ver/device-binding-response", + "@id": "", + "proofs": [ + { + "id": "libindy-presentation-0", + "path": "$.requested_proof.revealed_attrs.attr1_referent.raw" + } + ] } ``` Description of attributes: - `proofs` -- an array of proofs for different hardware keys which must match the `requests` array from the [device-binding-challenge](#device-binding-challenge) - - `id` -- reference to presentation of VC with an embeded hardware bound key - - `path` -- JsonPath to raw value of hardware bound public key within the attached presentation of the VC represented as did:key + - `id` -- reference to presentation of VC with an embeded hardware bound key + - `path` -- JsonPath to raw value of hardware bound public key within the attached presentation of the VC represented as did:key The `device-binding-response` must be attached to the `device_binding~attach` array of a `presentation` message defined by [RFC-0037](https://github.com/hyperledger/aries-rfcs/blob/main/features/0037-present-proof/README.md#presentation) or [RFC-0454](https://github.com/hyperledger/aries-rfcs/tree/main/features/0454-present-proof-v2#presentation). @@ -154,41 +156,42 @@ The following represents a presentation message with an attached libindy present **Present Proof v1** -```json= +```json { - "@type": "https://didcomm.org/present-proof/1.0/presentation", - "@id": "", - "comment": "some comment", - "presentations~attach": [ - { - "@id": "libindy-presentation-0", - "mime-type": "application/json", - "data": { - "base64": "" - } + "@type": "https://didcomm.org/present-proof/1.0/presentation", + "@id": "", + "comment": "some comment", + "presentations~attach": [ + { + "@id": "libindy-presentation-0", + "mime-type": "application/json", + "data": { + "base64": "" + } + } + ], + "device_binding~attach": [ + { + "@id": "device-binding-response-0", + "mime-type": "application/json", + "data": { + "base64": "", + "jws": { + "header": { + "kid": "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th" + }, + "protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)", + "signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)" } - ], - "device_binding~attach": [ - { - "@id": "device-binding-response-0", - "mime-type": "application/json", - "data": { - "base64": "", - "jws": { - "header": { - "kid": "did:key:z6MkmjY8GnV5i9YTDtPETC2uUAW6ejw3nk5mXF5yci5ab7th" - }, - "protected": "eyJhbGciOiJFZERTQSIsImlhdCI6MTU4Mzg4... (bytes omitted)", - "signature": "3dZWsuru7QAVFUCtTd0s7uc1peYEijx4eyt5... (bytes omitted)" - } - } - } - ] + } + } + ] } ``` **Present Proof v2** -```json= + +```json { "@type": "https://didcomm.org/present-proof/%VER/presentation", "@id": "", @@ -230,17 +233,16 @@ The following represents a presentation message with an attached libindy present ``` ## Reference + - [DIF Wallet Security Github Page](https://github.com/decentralized-identity/wallet-security) ## Drawbacks Including a hardware-bound public key (as an attribute) into a Verifiable Credential/AnonCred is necessary for this concept but introduces a globally unique and therefore trackable identifier. As this public key is revealed to the verifier, there is a higher risk of correlation. The Issuer must always use a hardware-bound key for a single credential and the Wallet should enforce to never reuse the key. Additionally, the holder should ideally be informed about the increased correlation risk by the wallet UX. - ## Rationale and alternatives - -The rationale behind this proposal is to formalize the way a holder wallet can proof the control of a (hardware-bound) key. +The rationale behind this proposal is to formalize the way a holder wallet can proof the control of a (hardware-bound) key. This proposal tries to extend existing protocols to reduce the implementation effort for existing solutions. It might be reasonable to include this only in a new version of the present proof protocol (e.g. present-proof v3). @@ -250,20 +252,19 @@ None to our knowledge. ## Unresolved questions -* What is the best way to reference hardware bound keys within VCs and presentations? - * Do we need a standardised attribute name for the hardware backed public key (e.g. "HardwareDid") - * Can we just reference the hardware key within the request object? - * Is it required to explicitly define the accepted signing algorithm within the `device-binding-challenge` object? -* What kind of key encoding do we choose? - * did:key, base64-encoded JWK and did:jwk in discussion - +- What is the best way to reference hardware bound keys within VCs and presentations? + - Do we need a standardised attribute name for the hardware backed public key (e.g. "HardwareDid") + - Can we just reference the hardware key within the request object? + - Is it required to explicitly define the accepted signing algorithm within the `device-binding-challenge` object? +- What kind of key encoding do we choose? + - did:key, base64-encoded JWK and did:jwk in discussion + ## 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#accepted). - -Name / Link | Implementation Notes ---- | --- - | +_Implementation Notes_ [may need to include a link to test results](/README.md#accepted). +| Name / Link | Implementation Notes | +| ----------- | -------------------- | +| | From 1f2b6ae13cfe0ac2b687e85e87b3e6604f7e0ef1 Mon Sep 17 00:00:00 2001 From: James Ebert Date: Tue, 4 Jun 2024 13:09:44 -0700 Subject: [PATCH 2/3] chore: move 0496 to adopted in mkdocs/index Signed-off-by: James Ebert --- index.md | 2 +- mkdocs.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/index.md b/index.md index feff6a829..227bd313f 100644 --- a/index.md +++ b/index.md @@ -28,6 +28,7 @@ * [0441: Prover and Verifier Best Practices for Proof Presentation](concepts/0441-present-proof-best-practices/README.md) (2024-05-01 — [`concept`](/tags.md#concept) [`credentials`](/tags.md#credentials)) * [0453: Issue Credential Protocol 2.0](features/0453-issue-credential-v2/README.md) (2021-04-15 — [`feature`](/tags.md#feature) [`decorator`](/tags.md#decorator) [`protocol`](/tags.md#protocol) [`credentials`](/tags.md#credentials) [`test-anomaly`](/tags.md#test-anomaly)) * [0454: Present Proof Protocol 2.0](features/0454-present-proof-v2/README.md) (2021-04-15 — [`feature`](/tags.md#feature) [`protocol`](/tags.md#protocol) [`credentials`](/tags.md#credentials) [`test-anomaly`](/tags.md#test-anomaly)) +* [0496: Transition to the Out of Band Protocol](features/0496-transition-to-oob-and-did-exchange/README.md) (2021-11-24 — [`feature`](/tags.md#feature) [`community-update`](/tags.md#community-update) [`test-anomaly`](/tags.md#test-anomaly)) * [0510: Presentation-Exchange Attachment format for requesting and presenting proofs](features/0510-dif-pres-exch-attach/README.md) (2020-07-21 — [`feature`](/tags.md#feature) [`protocol`](/tags.md#protocol) [`credentials`](/tags.md#credentials) [`test-anomaly`](/tags.md#test-anomaly)) * [0557: Discover Features Protocol v2.x](features/0557-discover-features-v2/README.md) (2024-05-01 — [`feature`](/tags.md#feature) [`protocol`](/tags.md#protocol) [`test-anomaly`](/tags.md#test-anomaly)) * [0592: Indy Attachment Formats for Requesting and Presenting Credentials](features/0592-indy-attachments/README.md) (2021-04-15 — [`feature`](/tags.md#feature) [`protocol`](/tags.md#protocol) [`credentials`](/tags.md#credentials) [`test-anomaly`](/tags.md#test-anomaly)) @@ -42,7 +43,6 @@ * [0049: Repudiation](concepts/0049-repudiation/README.md) (2019-03-01 — [`concept`](/tags.md#concept)) * [0050: Wallets](concepts/0050-wallets/README.md) (2018-07-01, [1 impl](concepts/0050-wallets/README.md#implementations) — [`concept`](/tags.md#concept)) * [0183: Revocation Notification 1.0](features/0183-revocation-notification/README.md) (2024-05-01 — [`feature`](/tags.md#feature) [`protocol`](/tags.md#protocol)) -* [0496: Transition to the Out of Band and DID Exchange Protocols](features/0496-transition-to-oob-and-did-exchange/README.md) (2021-11-24 — [`feature`](/tags.md#feature) [`community-update`](/tags.md#community-update) [`test-anomaly`](/tags.md#test-anomaly)) * [0519: Goal Codes](concepts/0519-goal-codes/README.md) (2021-04-15 — [`concept`](/tags.md#concept)) * [0587: Encryption Envelope v2](features/0587-encryption-envelope-v2/README.md) (2021-04-15 — [`feature`](/tags.md#feature)) * [0646: W3C Credential Exchange using BBS+ Signatures](features/0646-bbs-credentials/README.md) (2021-04-28 — [`feature`](/tags.md#feature)) diff --git a/mkdocs.yml b/mkdocs.yml index 026a21a13..d10196920 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -149,6 +149,7 @@ nav: - 0441 Prover and Verifier Best Practices for Proof Presentation: concepts/0441-present-proof-best-practices/README.md - 0453 Issue Credential Protocol 2.0: features/0453-issue-credential-v2/README.md - 0454 Present Proof Protocol 2.0: features/0454-present-proof-v2/README.md + - 0496 Transition to the Out of Band Protocol: features/0496-transition-to-oob-and-did-exchange/README.md - 0510 Presentation-Exchange Attachment format for requesting and presenting proofs: features/0510-dif-pres-exch-attach/README.md - 0557 Discover Features Protocol v2.x: features/0557-discover-features-v2/README.md - 0592 Indy Attachment Formats for Requesting and Presenting Credentials: features/0592-indy-attachments/README.md @@ -162,7 +163,6 @@ nav: - 0049 Repudiation: concepts/0049-repudiation/README.md - 0050 Wallets: concepts/0050-wallets/README.md - 0183 Revocation Notification 1.0: features/0183-revocation-notification/README.md - - 0496 Transition to the Out of Band and DID Exchange Protocols: features/0496-transition-to-oob-and-did-exchange/README.md - 0519 Goal Codes: concepts/0519-goal-codes/README.md - 0587 Encryption Envelope v2: features/0587-encryption-envelope-v2/README.md - 0646 W3C Credential Exchange using BBS+ Signatures: features/0646-bbs-credentials/README.md From b74b4acc43171057bc6b5417a2970bade8fdbd70 Mon Sep 17 00:00:00 2001 From: James Ebert Date: Fri, 7 Jun 2024 10:04:10 -0700 Subject: [PATCH 3/3] retrigger dco check Signed-off-by: James Ebert --- mkdocs.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index d10196920..826526691 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -251,4 +251,4 @@ nav: - 0303 V0.1 Credential Exchange (Deprecated): features/0303-v01-credential-exchange/README.md - 0317 Please ACK Decorator: features/0317-please-ack/README.md - 0348 Transition Message Type to HTTPs: features/0348-transition-msg-type-to-https/README.md - - 0627 Static Peer DIDs: features/0627-static-peer-dids/README.md + - 0627 Static Peer DIDs: features/0627-static-peer-dids/README.md \ No newline at end of file