diff --git a/0000-template-protocol.md b/0000-template-protocol.md index 2fbd9f255..927f1a3c3 100644 --- a/0000-template-protocol.md +++ b/0000-template-protocol.md @@ -13,7 +13,7 @@ One paragraph explanation of the feature. -> If the RFC you are proposing is **NOT** a protocol, please use [this template](https://github.com/hyperledger/aries-rfcs/tree/master/0000-template.md) as a starting point. +> If the RFC you are proposing is **NOT** a protocol, please use [this template](https://github.com/hyperledger/aries-rfcs/tree/main/0000-template.md) as a starting point. > When completing this template and before submitting as a PR, please remove the template text in sections (other than **Implementations**). The implementations section should remain as is. @@ -33,9 +33,9 @@ Protocol names are often either lower_snake_case or kebob-case. The non-version URI: https://didcomm.org/lets_do_lunch// -Message types and protocols are identified with special URIs that match certain conventions. See [Message Type and Protocol Identifier URIs](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md#message-type-and-protocol-identifier-uris) for more details. +Message types and protocols are identified with special URIs that match certain conventions. See [Message Type and Protocol Identifier URIs](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/README.md#message-type-and-protocol-identifier-uris) for more details. -The version of a protocol is declared carefully. See [Semver Rules for Protocols](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md#semver-rules-for-protocols) for details. +The version of a protocol is declared carefully. See [Semver Rules for Protocols](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/README.md#semver-rules-for-protocols) for details. ### Key Concepts @@ -50,7 +50,7 @@ variants. ### Roles -> See [this note](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols/roles-participants-etc.md) for definitions of the terms +> See [this note](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0003-protocols/roles-participants-etc.md) for definitions of the terms "role", "participant", and "party". Provides a formal name to each role in the protocol, says who and how many can @@ -61,7 +61,7 @@ credential must be known to the issuer"). The formal names for each role are important because they are used when [agents discover one another's -capabilities](https://github.com/hyperledger/aries-rfcs/tree/master/features/0031-discover-features); +capabilities](https://github.com/hyperledger/aries-rfcs/tree/main/features/0031-discover-features); an agent doesn't just claim that it supports a protocol; it makes a claim about which *roles* in the protocol it supports. An agent that supports credential issuance and an agent that supports credential holding may have very different @@ -76,7 +76,7 @@ errors, and what should happen to state as a result. A formal representation of this information is provided in a _state machine matrix_. It lists events as columns, and states as rows; a cell answers the question, "If I am in state X (=row), and event Y (=column) occurs, what happens to my state?" The [Tic Tac -Toe example](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/tictactoe/README.md#states) is typical. +Toe example](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/tictactoe/README.md#states) is typical. [Choreography Diagrams]( https://www.visual-paradigm.com/guide/bpmn/bpmn-orchestration-vs-choreography-vs-collaboration/#bpmn-choreography) @@ -92,8 +92,8 @@ the matrix form is used in many early RFCs. We leave it up to the community to settle on whether it wants to strongly recommend specific diagram types. -The formal names for each state are important, as they are used in [`ack`s](https://github.com/hyperledger/aries-rfcs/tree/master/features/0015-acks) -and [`problem-report`s](https://github.com/hyperledger/aries-rfcs/tree/master/features/0035-report-problem)). +The formal names for each state are important, as they are used in [`ack`s](https://github.com/hyperledger/aries-rfcs/tree/main/features/0015-acks) +and [`problem-report`s](https://github.com/hyperledger/aries-rfcs/tree/main/features/0035-report-problem)). For example, a `problem-report` message declares which state the sender arrived at because of the problem. This helps other participants to react to errors with confidence. Formal state names are also used in the @@ -103,14 +103,14 @@ By convention, state names use lower-kebab-case. They are compared case-sensitively. State management in protocols is a deep topic. For more information, please -see [State Details and State Machines](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/state-details.md). +see [State Details and State Machines](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/state-details.md). ### Messages This section describes each message in the protocol. It should also note the names and versions of messages from other message families that are adopted by the -protocol (e.g., an [`ack`](https://github.com/hyperledger/aries-rfcs/tree/master/features/0015-acks) -or a [`problem-report`](https://github.com/hyperledger/aries-rfcs/tree/master/features/0035-report-problem)). +protocol (e.g., an [`ack`](https://github.com/hyperledger/aries-rfcs/tree/main/features/0015-acks) +or a [`problem-report`](https://github.com/hyperledger/aries-rfcs/tree/main/features/0035-report-problem)). Typically this section is written as a narrative, showing each message type in the context of an end-to-end sample interaction. All possible fields may not appear; an exhaustive catalog is saved for the "Reference" @@ -118,7 +118,7 @@ section. Sample messages that are presented in the narrative should also be checked in next to the markdown of the RFC, in [DIDComm Plaintext format]( -https://github.com/hyperledger/aries-rfcs/tree/master/features/0044-didcomm-file-and-mime-types#didcomm-messages-dm). +https://github.com/hyperledger/aries-rfcs/tree/main/features/0044-didcomm-file-and-mime-types#didcomm-messages-dm). The _message_ element of a message type URI are typically lower_camel_case or lower-kebab-case, matching the style of the protocol. JSON items in messages are lower_camel_case and inconsistency in the @@ -183,7 +183,7 @@ needs to be known about all message fields, this is where the data type, validation rules, and semantics of each field in each message type are details. Enumerating possible values, or providing ABNF or regexes is encouraged. Following conventions such as [those for date- -and time-related fields](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0074-didcomm-best-practices#date-time-conventions) +and time-related fields](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0074-didcomm-best-practices#date-time-conventions) can save a lot of time here. Each message type should be associated with one or more roles in the @@ -211,15 +211,15 @@ If communication in the protocol involves humans, then localization of message content may be relevant. Default settings for localization of all messages in the protocol can be specified in an `l10n.json` file described here and checked in with the RFC. See ["Decorators at Message -Type Scope"](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0011-decorators#decorator-scope) -in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0043-l10n). +Type Scope"](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0011-decorators#decorator-scope) +in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/tree/main/features/0043-l10n). ### Codes Catalog If the protocol has a formally defined catalog of codes (e.g., for errors or for statuses), define them in this section. See ["Message Codes and -Catalogs"](https://github.com/hyperledger/aries-rfcs/blob/master/features/0043-l10n/README.md#message-codes-and-catalogs) -in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/blob/master/features/0043-l10n). +Catalogs"](https://github.com/hyperledger/aries-rfcs/blob/main/features/0043-l10n/README.md#message-codes-and-catalogs) +in the [Localization RFC](https://github.com/hyperledger/aries-rfcs/blob/main/features/0043-l10n). ## Drawbacks diff --git a/0000-template.md b/0000-template.md index 865d996e8..707ba5ae2 100644 --- a/0000-template.md +++ b/0000-template.md @@ -11,7 +11,7 @@ One paragraph explanation of the feature. -> NOTE: If you are creating a **protocol** RFC, please use [this template](https://github.com/hyperledger/aries-rfcs/blob/master/0000-template-protocol.md) instead. +> NOTE: If you are creating a **protocol** RFC, please use [this template](https://github.com/hyperledger/aries-rfcs/blob/main/0000-template-protocol.md) instead. ## Motivation diff --git a/concepts/0003-protocols/tictactoe/README.md b/concepts/0003-protocols/tictactoe/README.md index 8dce429b3..cbfb06412 100644 --- a/concepts/0003-protocols/tictactoe/README.md +++ b/concepts/0003-protocols/tictactoe/README.md @@ -29,7 +29,7 @@ capture 3 cells of the grid in a straight line. ### Name and Version This defines the `tictactoe` protocol, version 1.x, as identified by the -following [PIURI](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols#message-type-and-protocol-identifier-uris): +following [PIURI](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0003-protocols#message-type-and-protocol-identifier-uris): did:sov:SLfEi9esrjzybysFxQZbfq;spec/tictactoe/1.0 diff --git a/concepts/0004-agents/README.md b/concepts/0004-agents/README.md index 9bf963d1e..dabe7e47c 100644 --- a/concepts/0004-agents/README.md +++ b/concepts/0004-agents/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-01-15 - Status Note: On a standards track and beginning to influence many mental models, but not yet [ADOPTED](/README.md#rfc-lifecycle). -- Supersedes: [Indy HIPE 0002](https://github.com/hyperledger/indy-hipe/tree/master/text/0002-agents) +- Supersedes: [Indy HIPE 0002](https://github.com/hyperledger/indy-hipe/tree/main/text/0002-agents) - Start Date: 2017-11-01 (approx, backdated) - Tags: [concept](/tags.md#concept) @@ -169,7 +169,7 @@ Here are some thought questions to clarify intent: We said it's hard to provide a recipe for an agent without specifics. However, the majority of agents _do_ have two things in common: they listen to and process A2A messages, and they use a [wallet]( -https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md) +https://github.com/hyperledger/indy-hipe/blob/main/text/0013-wallets/README.md) to manage keys, credentials, and other sensitive material. Unless you have uses cases that involve IoT, cron jobs, or web hooks, your agent is likely to fit this mold. @@ -236,7 +236,7 @@ in the DID Doc of the recipient, and finding an intersection between transports they use, and transports the sender can speak. Line 3 requires the keys of the sender, which would normally be held in a [wallet]( -https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md). +https://github.com/hyperledger/indy-hipe/blob/main/text/0013-wallets/README.md). If you are building this sort of code using Aries technology, you will certainly want to use [Aries Agent SDK]( @@ -253,7 +253,7 @@ or in its Getting Started Guide. * Hang out and ask questions on `#aries` on [chat.hyperledger.org](https://chat.hyperledger.org). * Use the mailing list: [aries@lists.hyperledger.org](mailto:aries@lists.hyperledger.org) -* Follow the Aries Cloud Agent - Python [Getting Started Guide (for developers)](https://github.com/hyperledger/aries-cloudagent-python/tree/master/docs/GettingStartedAriesDev) +* Follow the Aries Cloud Agent - Python [Getting Started Guide (for developers)](https://github.com/hyperledger/aries-cloudagent-python/tree/main/docs/GettingStartedAriesDev) * Study the [Aries Protocol Test Suite](https://github.com/hyperledger/aries-protocol-test-suite) | * Study the sample mobile agent at [github.com/sovrin-foundation/connector-app](https://github.com/sovrin-foundation/connector-app). * Browse other [RFCs](../../index.md). @@ -365,7 +365,7 @@ that gap. ###### Identity Wallets "Identity wallet" is a term that's [carefully defined]( -https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md#what-is-an-identity-wallet) +https://github.com/hyperledger/indy-hipe/blob/main/text/0013-wallets/README.md#what-is-an-identity-wallet) in our ecosystem, and in strict, technical usage it maps to a concept much closer to "database" than "agent". This is because it is an inert storage container, not an active interacter. However, in @@ -398,7 +398,7 @@ A cron job that runs once a night at Faber, scanning a database and revoking credentials that have changes status during the day, is an agent for Faber. This is true even though it doesn't listen for incoming messages (it only talks [revocation protocol]( -https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation) to the ledger). In order to +https://github.com/hyperledger/indy-hipe/tree/main/text/0011-cred-revocation) to the ledger). In order to talk that protocol, it must hold keys delegated by Faber, and it is surely Faber's fiduciary. diff --git a/concepts/0020-message-types/README.md b/concepts/0020-message-types/README.md index 5ffd13f54..18d119b56 100644 --- a/concepts/0020-message-types/README.md +++ b/concepts/0020-message-types/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-05-24 - Status Note: -- Supersedes: [HIPE 0021 Message Types](https://github.com/hyperledger/indy-hipe/tree/master/text/0021-message-types) +- Supersedes: [HIPE 0021 Message Types](https://github.com/hyperledger/indy-hipe/tree/main/text/0021-message-types) - Start Date: 2018-07-06 - Tags: [concept](/tags.md#concept) diff --git a/concepts/0021-didcomm-message-anatomy/README.md b/concepts/0021-didcomm-message-anatomy/README.md index 41c59442b..34e50ecfe 100644 --- a/concepts/0021-didcomm-message-anatomy/README.md +++ b/concepts/0021-didcomm-message-anatomy/README.md @@ -62,7 +62,7 @@ The most important concepts to introduce about these conventions are the followi #### Message Type Every message contains a message type which allows the context of the message to be established and therefore process the content, -see [here](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0020-message-types/README.md) for more information. It is also important to +see [here](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0020-message-types/README.md) for more information. It is also important to note that in DIDComm, the message identification does not just identify the message, the message type also identifies the associated protocol. These protocols are essentially a group of related messages that are together required to achieve some form of multi-step flow see [here](../0003-protocols/README.md) for more information. diff --git a/concepts/0029-message-trust-contexts/README.md b/concepts/0029-message-trust-contexts/README.md index 211403820..a5e2815bb 100644 --- a/concepts/0029-message-trust-contexts/README.md +++ b/concepts/0029-message-trust-contexts/README.md @@ -133,7 +133,7 @@ MTCs apply to the entirety of the associated message's attributes. However, _emb attachments present the unique situation of nested content with the potential for a trust context that differs from the parent message. -The [attachment descriptor](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#embedding), +The [attachment descriptor](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#embedding), used for both _embedded_ and _appended_ attachments, shares the same MTC as the parent message. Unpacked attachment data have their own Trust Contexts populated as appropriate depending on how the data was retrieved, whether the attachment is signed, whether an integrity checksum was provided and verified, etc. diff --git a/concepts/0047-json-ld-compatibility/README.md b/concepts/0047-json-ld-compatibility/README.md index 4c3961f24..d6c2749a8 100644 --- a/concepts/0047-json-ld-compatibility/README.md +++ b/concepts/0047-json-ld-compatibility/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-02-20 - Status Note: Has guided Indy design choices for several months. Not yet ratified by greater Aries community. -- Supersedes: [Indy HIPE 0035](https://github.com/hyperledger/indy-hipe/tree/master/text/0035-json-ld-compatibility) +- Supersedes: [Indy HIPE 0035](https://github.com/hyperledger/indy-hipe/tree/main/text/0035-json-ld-compatibility) - Start Date: 2019-01-23 - Tags: [concept](/tags.md#concept), [decorator](/tags.md#decorator) diff --git a/concepts/0049-repudiation/README.md b/concepts/0049-repudiation/README.md index bedfdd3d4..e75bf153b 100644 --- a/concepts/0049-repudiation/README.md +++ b/concepts/0049-repudiation/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-03-01 - Status Note: Well understood and baked into various protocol designs and DIDComm processes--but not yet ratified by the larger Aries community. -- Supersedes: [Indy HIPE 0037]( https://github.com/hyperledger/indy-hipe/tree/master/text/0037-repudiation) +- Supersedes: [Indy HIPE 0037]( https://github.com/hyperledger/indy-hipe/tree/main/text/0037-repudiation) - Start Date: 2018-03-01 (backdated) - Tags: [concept](/tags.md#concept) diff --git a/concepts/0050-wallets/README.md b/concepts/0050-wallets/README.md index 561034847..ee8b90313 100644 --- a/concepts/0050-wallets/README.md +++ b/concepts/0050-wallets/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2018-07-01 - Status Note: Fully implemented in Indy SDK, but not yet socialized well in the broader Aries community. Needs some updates to promote better key management; see related RFC about [lox](../../features/0042-lox/README.md). -- Supersedes: [Indy HIPE 0013]( https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets) +- Supersedes: [Indy HIPE 0013]( https://github.com/hyperledger/indy-hipe/tree/main/text/0013-wallets) - Start Date: 2018-05-22 - Tags: [concept](/tags.md#concept) diff --git a/concepts/0074-didcomm-best-practices/README.md b/concepts/0074-didcomm-best-practices/README.md index 3a1bbb8c1..f0c744cac 100644 --- a/concepts/0074-didcomm-best-practices/README.md +++ b/concepts/0074-didcomm-best-practices/README.md @@ -398,7 +398,7 @@ to make the content as useful as possible: with (possibly) many documents. * Hyperlinks from one RFC to another should be in relative form (`../features/my-rfc/README.md`), not in absolute form (`/features/my-rfc/README.md`) or external form -(`https://github.com/hyperledger/aries-rfcs/blob/master/features/my-rfc/README.md`). +(`https://github.com/hyperledger/aries-rfcs/blob/main/features/my-rfc/README.md`). This lets us move or embed the content, and it prevents branch names from cluttering the hyperlink. diff --git a/concepts/0104-chained-credentials/README.md b/concepts/0104-chained-credentials/README.md index 09a61cc1c..f3da54cc9 100644 --- a/concepts/0104-chained-credentials/README.md +++ b/concepts/0104-chained-credentials/README.md @@ -129,11 +129,11 @@ A chained credential delivers these features by obeying some special conventions When a presentation is created from a chained credential, `provenanceProofs` is either disclosed (for non-ZKP proofs), or is used as evidence to prove the same thing (for ZKPs). -3. It is associated (through a name in its `type` field array and through a URI in its `trustFrameworkURI` field) with a [trust framework](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0103-indirect-identity-control/README.md#proxy-trust-framework) that describes provenancing rules. For general chained credentials, this is optional; for delegate credentails, it is required. The trust framework may partially describe the semantics of some schema variants for a family of chained credentials, as well as how provenance is attenuated or categorized. For example, a trust framework jointly published by Ur Wheelz and other car rental companies might describe delegate credential schemas for car owners, car rental offices, drivers, insurers, maintenance staff, and guest users of cars. It might specify that the permissions delegatable in these credentials include `drive`, `maintain`, `rent`, `sell`, `retire`, `delegate-further`, and so forth. The trust framework would do more than enumerate these values; it would define exactly what they mean, how they interact with one another, and what permissions are expected to be in force in various circumstances. +3. It is associated (through a name in its `type` field array and through a URI in its `trustFrameworkURI` field) with a [trust framework](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0103-indirect-identity-control/README.md#proxy-trust-framework) that describes provenancing rules. For general chained credentials, this is optional; for delegate credentails, it is required. The trust framework may partially describe the semantics of some schema variants for a family of chained credentials, as well as how provenance is attenuated or categorized. For example, a trust framework jointly published by Ur Wheelz and other car rental companies might describe delegate credential schemas for car owners, car rental offices, drivers, insurers, maintenance staff, and guest users of cars. It might specify that the permissions delegatable in these credentials include `drive`, `maintain`, `rent`, `sell`, `retire`, `delegate-further`, and so forth. The trust framework would do more than enumerate these values; it would define exactly what they mean, how they interact with one another, and what permissions are expected to be in force in various circumstances. 4. The reputation of non-root holders in a provenance chain become irrelevant as far as credential trust is concerned--trust is based on an unbroken chain back to a root public attester, not on published, permanent characteristics of secondary issuers. Only the root attester needs to have a public DID. Other issuer keys and DIDs can be private and pairwise. -5. If it is a delegate credential, it also meets all the requirements to be a __proxy credential__ as described in [Aries RFC 0103: Indirect Identity Control](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0103-indirect-identity-control/README.md#proxy-credential). Specifically: +5. If it is a delegate credential, it also meets all the requirements to be a __proxy credential__ as described in [Aries RFC 0103: Indirect Identity Control](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0103-indirect-identity-control/README.md#proxy-credential). Specifically: * It uses `credentialSubject.holder.*` fields to bind it to a particular holder, if applicable. @@ -159,7 +159,7 @@ Here is JSON that might embody credentials C1, C2, and C3 from our use case. Not ```jsonc { - "@context": ["https://w3.org/2018/credentials/v1", "https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0104-delegatable-credentials"], + "@context": ["https://w3.org/2018/credentials/v1", "https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0104-delegatable-credentials"], "type": ["VerifiableCredential", "Proxy.D/CarRentalTF/1.0/subsidiary"], "schema": "WwogICJAY29udGV4dCIsIC8vSlN... (clipped for brevity) ...ob2x", "provenanceProofs": [ diff --git a/concepts/0250-rich-schemas/README.md b/concepts/0250-rich-schemas/README.md index 8783d60cc..6ca616744 100644 --- a/concepts/0250-rich-schemas/README.md +++ b/concepts/0250-rich-schemas/README.md @@ -2,8 +2,8 @@ - Author: [Ken Ebert](ken@sovrin.org), [Brent Zundel](brent.zundel@evernym.com) - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-10-08 -- Status Note: Port of [this HIPE](https://github.com/hyperledger/indy-hipe/tree/master/text/0119-rich-schemas/README.md) -- Supersedes: [this HIPE](https://github.com/hyperledger/indy-hipe/tree/master/text/0119-rich-schemas/README.md) +- Status Note: Port of [this HIPE](https://github.com/hyperledger/indy-hipe/tree/main/text/0119-rich-schemas/README.md) +- Supersedes: [this HIPE](https://github.com/hyperledger/indy-hipe/tree/main/text/0119-rich-schemas/README.md) - Start Date: 2019-03-19 - Tags: [concept](/tags.md#concept), [rich-schemas](/tags.md#rich-schemas) diff --git a/concepts/0257-private-credential-issuance/README.md b/concepts/0257-private-credential-issuance/README.md index 38a3da0a8..107af2adf 100644 --- a/concepts/0257-private-credential-issuance/README.md +++ b/concepts/0257-private-credential-issuance/README.md @@ -41,7 +41,7 @@ An issuer needs to register a credential definition and a revocation registry on ### Delegatable credentials as a tool -[Delegatable Credentials](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0104-delegatable-credentials) are a useful tool that we can use to solve this problem. They function like special Object Capabilities (OCAP) tokens, and may offer the beginnings of a solution. They definitely address the delegation use cases, at least. Their properties include: +[Delegatable Credentials](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0104-delegatable-credentials) are a useful tool that we can use to solve this problem. They function like special Object Capabilities (OCAP) tokens, and may offer the beginnings of a solution. They definitely address the delegation use cases, at least. Their properties include: * A root issuer that is willing to go through setup and maintenance hassle creates a normal Indy credential and issues it to a normal Indy holder. diff --git a/concepts/0270-interop-test-suite/README.md b/concepts/0270-interop-test-suite/README.md index b349b9b92..6a441493d 100644 --- a/concepts/0270-interop-test-suite/README.md +++ b/concepts/0270-interop-test-suite/README.md @@ -3,7 +3,7 @@ - Status: [PROPOSED](/README.md#proposed) - Since: 2019-10-25 - Status Note: Codifies some thinking about scope and mental model that are already socialized. Provides some new thinking as well. -- Supersedes: Partially, and in some ways, [Indy HIPE 0015](https://github.com/hyperledger/indy-hipe/blob/master/text/0015-agent-test-suite-interface/README.md) and [Indy HIPE 0016](https://github.com/hyperledger/indy-hipe/blob/master/text/0016-agent-test-suite-v1/README.md). Also, represents answers to questions that the community first posed in [this HackMD doc](https://hackmd.io/JW5b9xYCRGKqyqhVevTZ_g) and first attempted to answer in the [indy-agent repo](https://github.com/hyperledger/indy-agent). +- Supersedes: Partially, and in some ways, [Indy HIPE 0015](https://github.com/hyperledger/indy-hipe/blob/main/text/0015-agent-test-suite-interface/README.md) and [Indy HIPE 0016](https://github.com/hyperledger/indy-hipe/blob/main/text/0016-agent-test-suite-v1/README.md). Also, represents answers to questions that the community first posed in [this HackMD doc](https://hackmd.io/JW5b9xYCRGKqyqhVevTZ_g) and first attempted to answer in the [indy-agent repo](https://github.com/hyperledger/indy-agent). - Start Date: 2018-10-25 - Tags: [concept](/tags.md#concept) diff --git a/concepts/0289-toip-stack/README.md b/concepts/0289-toip-stack/README.md index a93230f69..cbb87aa5b 100644 --- a/concepts/0289-toip-stack/README.md +++ b/concepts/0289-toip-stack/README.md @@ -326,7 +326,7 @@ This RFC will be updated to track the evolution of the ToIP stack as it is furth 7. Uniform Resource Names (URNs), [RFC 8141](https://tools.ietf.org/html/rfc8141), April 2017; accessed November 2, 2019. 8. Greg Slepak, Christopher Allen, et al, [Decentralized Public Key Infrastructure](https://github.com/WebOfTrustInfo/rwot1-sf/blob/master/draft-documents/Decentralized-Public-Key-Infrastructure-CURRENT.md), December 2015, accessed January 24, 2020. 9. W3C Credentials Community Group, [DID Method Registry](https://w3c-ccg.github.io/did-method-registry/), June 2019; accessed July 6, 2019. -10. Daniel Hardman, [DID Communication](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0005-didcomm/README.md), January 2019; accessed July 6, 2019. +10. Daniel Hardman, [DID Communication](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0005-didcomm/README.md), January 2019; accessed July 6, 2019. 11. Daniel Hardman et al, [Peer DID Method 1.0 Specification](https://openssi.github.io/peer-did-method-spec/), July 2019; accessed July 6, 2019. 12. Drummond Reed, Jason Law, Daniel Hardman, Mike Lodder, [DKMS Design and Architecture V4](http://bit.ly/dkms-v4), March 2019; accessed November 2, 2019. 13. Samuel M. Smith, [Key Event Receipt Infrastructure (KERI)](https://arxiv.org/abs/1907.02143) , July 2019, accessed February 4, 2020. diff --git a/concepts/0302-aries-interop-profile/README.md b/concepts/0302-aries-interop-profile/README.md index e0ebb0fcf..ac2760b16 100644 --- a/concepts/0302-aries-interop-profile/README.md +++ b/concepts/0302-aries-interop-profile/README.md @@ -1,7 +1,7 @@ # 0302: Aries Interop Profile - Authors: [Stephen Curran](mailto:swcurran@cloudcompass.ca), [John Jordan](mailto:john.jordan@gov.bc.ca) Province of British Columbia -- Status: [ACCEPTED](https://github.com/hyperledger/aries-rfcs/blob/master/README.md#accepted) +- Status: [ACCEPTED](https://github.com/hyperledger/aries-rfcs/blob/main/README.md#accepted) - Since: 2021-01-06 - Status Note: This RFC defines an Aries Interop Profile process and Aries Interop Profile versions - Supersedes: @@ -287,7 +287,7 @@ This is a typical approach to creating an early protocol certification program. 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](https://github.com/hyperledger/aries-rfcs/blob/master/README.md#accepted). +_Implementation Notes_ [may need to include a link to test results](https://github.com/hyperledger/aries-rfcs/blob/main/README.md#accepted). Name / Link | Implementation Notes diff --git a/concepts/0345-community-coordinated-update/README.md b/concepts/0345-community-coordinated-update/README.md index c023722b1..6669414e4 100644 --- a/concepts/0345-community-coordinated-update/README.md +++ b/concepts/0345-community-coordinated-update/README.md @@ -58,7 +58,7 @@ This step is formalized by writing an RFC detailing which changes are expected i ## Reference -This process should only be used for changes that are not detectable via the [Discover Features protocol](https://github.com/hyperledger/aries-rfcs/blob/master/features/0031-discover-features/README.md), either because the Discover Features Protocol cannot yet be run or the Discover Features Protocol does not reveal the change. +This process should only be used for changes that are not detectable via the [Discover Features protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0031-discover-features/README.md), either because the Discover Features Protocol cannot yet be run or the Discover Features Protocol does not reveal the change. #### Changes NOT applicable to this process @@ -89,7 +89,7 @@ This process was discussed in [Issue 318](https://github.com/hyperledger/aries-r 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](https://github.com/hyperledger/aries-rfcs/blob/master/README.md#accepted). +*Implementation Notes* [may need to include a link to test results](https://github.com/hyperledger/aries-rfcs/blob/main/README.md#accepted). Name / Link | Implementation Notes --- | --- diff --git a/concepts/0346-didcomm-between-two-mobile-agents/README.md b/concepts/0346-didcomm-between-two-mobile-agents/README.md index 736fb4ce3..56bf052d7 100644 --- a/concepts/0346-didcomm-between-two-mobile-agents/README.md +++ b/concepts/0346-didcomm-between-two-mobile-agents/README.md @@ -107,7 +107,7 @@ In other suggested message formatting protocol Alice would provide a list of rou # Related art [related-art] #prior-art -Aries-rfc [Aries RFC 0046: Mediators and Relays](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0046-mediators-and-relays) +Aries-rfc [Aries RFC 0046: Mediators and Relays](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0046-mediators-and-relays) # Prior art [prior-art]: #prior-art @@ -122,7 +122,7 @@ Can a cloud agent have their own army of servers that just basically looks into 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](https://github.com/hyperledger/aries-rfcs/blob/master/README.md#accepted). +*Implementation Notes* [may need to include a link to test results](https://github.com/hyperledger/aries-rfcs/blob/main/README.md#accepted). Name / Link | Implementation Notes --- | --- diff --git a/concepts/0420-rich-schemas-common/README.md b/concepts/0420-rich-schemas-common/README.md index 6d9045c7c..dfc085988 100644 --- a/concepts/0420-rich-schemas-common/README.md +++ b/concepts/0420-rich-schemas-common/README.md @@ -12,7 +12,7 @@ A low-level description of the components of an anonymous credential ecosystem that supports rich schemas, W3C Verifiable Credentials and Presentations, and correspondingly rich presentation requests. -Please see [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) +Please see [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) for high-level description. This RFC provides more low-level description of Rich Schema objects defining how they are identified and referenced. @@ -20,7 +20,7 @@ It also defines a general template and common part for all Rich Schema objects. ## Motivation -Please see [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) +Please see [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) for use cases and high-level description of why Rich Schemas are needed. This RFC serves as a low-level design of common parts between all Rich Schema objects, and can help developers to @@ -138,7 +138,7 @@ Any write request for Rich Schema object has the same fields: 'ver': # string ``` - `id` is a unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the `content` field) -- The `content` field here contains a Rich Schema object in JSON-LD format (see [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas)). +- The `content` field here contains a Rich Schema object in JSON-LD format (see [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas)). It's passed and stored as-is. The `content` field must be serialized in the canonical form. The canonicalization scheme we recommend is the IETF draft [JSON Canonicalization Scheme (JCS).](https://tools.ietf.org/id/draft-rundgren-json-canonicalization-scheme-16.html) @@ -249,9 +249,9 @@ error: { ``` ## Reference -- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [0249: Aries Rich Schema Contexts](https://github.com/hyperledger/aries-rfcs/tree/master/features/0249-rich-schema-contexts) -- [0281: Aries Rich Schemas](https://github.com/hyperledger/aries-rfcs/tree/master/features/0281-rich-schemas) +- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [0249: Aries Rich Schema Contexts](https://github.com/hyperledger/aries-rfcs/tree/main/features/0249-rich-schema-contexts) +- [0281: Aries Rich Schemas](https://github.com/hyperledger/aries-rfcs/tree/main/features/0281-rich-schemas) ## Drawbacks diff --git a/concepts/0430-machine-readable-governance-frameworks/README.md b/concepts/0430-machine-readable-governance-frameworks/README.md index 5d474608b..47f2eabe1 100644 --- a/concepts/0430-machine-readable-governance-frameworks/README.md +++ b/concepts/0430-machine-readable-governance-frameworks/README.md @@ -59,7 +59,7 @@ Each problem domain will probably have unique requirements. Therefore, we start { "@context": [ // The first context must be this RFC's context. It defines core properties. - "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/context.jsonld", + "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/context.jsonld", // Additional contexts can be added to extend. "https://kmk.org/uni-accred-trust-fw" ], diff --git a/concepts/0430-machine-readable-governance-frameworks/context.jsonld b/concepts/0430-machine-readable-governance-frameworks/context.jsonld index 9aa391f15..1eae0fd2c 100644 --- a/concepts/0430-machine-readable-governance-frameworks/context.jsonld +++ b/concepts/0430-machine-readable-governance-frameworks/context.jsonld @@ -1,17 +1,17 @@ { "@context": { - "name": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#name", - "version": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#version", - "logo": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#logo", - "description": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#description", - "docs_uri": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#docs_uri", - "topics": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#topics", - "geos": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#geos", - "jurisdictions": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#jurisdictions", - "roles": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#roles", - "privileges": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#privileges", - "duties": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#duties", - "define": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#define", - "rules": "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks/README.md#rules" + "name": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#name", + "version": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#version", + "logo": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#logo", + "description": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#description", + "docs_uri": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#docs_uri", + "topics": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#topics", + "geos": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#geos", + "jurisdictions": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#jurisdictions", + "roles": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#roles", + "privileges": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#privileges", + "duties": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#duties", + "define": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#define", + "rules": "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks/README.md#rules" } } \ No newline at end of file diff --git a/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19.md b/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19.md index 45bba74a6..bdfcbe0df 100644 --- a/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19.md +++ b/concepts/0430-machine-readable-governance-frameworks/gov-fw-covid-19.md @@ -1,7 +1,7 @@ ```jsonc { "@context": [ - "https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0430-machine-readable-governance-frameworks", + "https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0430-machine-readable-governance-frameworks", "https://fightthevirus.org/covid19-fw" ], "name": "COVID-19 Creds" diff --git a/concepts/0440-kms-architectures/README.md b/concepts/0440-kms-architectures/README.md index 0a853154d..cb872cd9d 100644 --- a/concepts/0440-kms-architectures/README.md +++ b/concepts/0440-kms-architectures/README.md @@ -3,7 +3,7 @@ - Status: [PROPOSED](/README.md#proposed) - Since: 2020-03-06 - Status Note: Proposed -- Supersedes: [Wallets](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0050-wallets/README.md), uses concepts from [LOX](https://github.com/hyperledger/aries-rfcs/blob/master/features/0042-lox/README.md) +- Supersedes: [Wallets](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0050-wallets/README.md), uses concepts from [LOX](https://github.com/hyperledger/aries-rfcs/blob/main/features/0042-lox/README.md) - Start Date: 2019-12-02 - Tags: [concept](/tags.md#concept) @@ -48,7 +48,7 @@ The components are listed below and described in detail in the following section 1. LOX - * Handle user authentication * Access control enforcement - * Session/context establishment and management to the previous layers as described [here](https://github.com/hyperledger/aries-rfcs/blob/master/features/0042-lox/README.md). + * Session/context establishment and management to the previous layers as described [here](https://github.com/hyperledger/aries-rfcs/blob/main/features/0042-lox/README.md). ## Architecture @@ -161,7 +161,7 @@ Upon authentication to LOX, LOX should establish connections to the enclave comp which should appear opaque to the client. LOX may need to authenticate to the enclave component or persistence component depending on where client access credentials are stored by implementors. Its preferable to store these in keychains or keystores if possible where the access is determined by the operating system and can include stronger mechanisms like -TouchID or FaceID and hardware tokens in addition to passwords or pins. As described in [LOX](https://github.com/hyperledger/aries-rfcs/blob/master/features/0042-lox/README.md), +TouchID or FaceID and hardware tokens in addition to passwords or pins. As described in [LOX](https://github.com/hyperledger/aries-rfcs/blob/main/features/0042-lox/README.md), the credentials for accessing the enclave and persistence layer can then be retrieved or generated if the client is new and stored in a secure manner. diff --git a/concepts/0441-present-proof-best-practices/README.md b/concepts/0441-present-proof-best-practices/README.md index 1073f6c89..92e446811 100644 --- a/concepts/0441-present-proof-best-practices/README.md +++ b/concepts/0441-present-proof-best-practices/README.md @@ -103,7 +103,7 @@ are semantically equivalent. ##### Verifier Non-Revocation Interval Formulation -The verifier MUST specify, as current [INDY-HIPE 11](https://github.com/hyperledger/indy-hipe/blob/master/text/0011-cred-revocation/README.md) notes, the same integer EPOCH time for both ends of the interval, or else omit the `"from"` key and value. In effect, where the presentation request specifies a non-revocation interval, the verifier MUST request a non-revocation instant. +The verifier MUST specify, as current [INDY-HIPE 11](https://github.com/hyperledger/indy-hipe/blob/main/text/0011-cred-revocation/README.md) notes, the same integer EPOCH time for both ends of the interval, or else omit the `"from"` key and value. In effect, where the presentation request specifies a non-revocation interval, the verifier MUST request a non-revocation instant. ##### Prover Non-Revocation Interval Processing @@ -164,7 +164,7 @@ When constructing a proof request, the verifier SHOULD express the minimum/maxim ## Reference * [RFC 0037](../../features/0037-present-proof/README.md): Present Proof protocol -* [INDY-HIPE 11](https://github.com/hyperledger/indy-hipe/blob/master/text/0011-cred-revocation/README.md): Indy revocation. +* [INDY-HIPE 11](https://github.com/hyperledger/indy-hipe/blob/main/text/0011-cred-revocation/README.md): Indy revocation. ## Implementations diff --git a/features/0019-encryption-envelope/README.md b/features/0019-encryption-envelope/README.md index 3eee1b08b..a2e89a445 100644 --- a/features/0019-encryption-envelope/README.md +++ b/features/0019-encryption-envelope/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-05-04 - Status Note: -- Supersedes: [INDY 0028 Wire Level Format](https://github.com/hyperledger/indy-hipe/tree/master/text/0028-wire-message-format) +- Supersedes: [INDY 0028 Wire Level Format](https://github.com/hyperledger/indy-hipe/tree/main/text/0028-wire-message-format) - Start Date: 2018-07-10 (approximate, backdated) - Tags: [feature](/tags.md#feature) diff --git a/features/0023-did-exchange/README.md b/features/0023-did-exchange/README.md index fe81b5435..583df639b 100644 --- a/features/0023-did-exchange/README.md +++ b/features/0023-did-exchange/README.md @@ -415,7 +415,7 @@ When Peer DIDs are used in an exchange, it is likely that both the _requester_ a * [Agent to Agent Communication Video](https://drive.google.com/file/d/1PHAy8dMefZG9JNg87Zi33SfKkZvUvXvx/view) * [Agent to Agent Communication Presentation](https://docs.google.com/presentation/d/1H7KKccqYB-2l8iknnSlGt7T_sBPLb9rfTkL-waSCux0/edit#slide=id.p) * Problem_report message adopted into message family, following form defined by the [Problem Report HIPE](https://github.com/hyperledger/indy-hipe/blob/6a5e4fe2d7e14953cd8e3aed07d886176332e696/text/error-handling/README.md) -* [RFC0519 Goal Codes](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0519-goal-codes/README.md) +* [RFC0519 Goal Codes](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0519-goal-codes/README.md) ## Drawbacks diff --git a/features/0024-didcomm-over-xmpp/README.md b/features/0024-didcomm-over-xmpp/README.md index 894aab3c5..8275dfe4b 100644 --- a/features/0024-didcomm-over-xmpp/README.md +++ b/features/0024-didcomm-over-xmpp/README.md @@ -4,7 +4,7 @@ - Status: [PROPOSED](/README.md#proposed) - Since: 2019-06-14 - Status Note: , moving from Indy to Aries. -- Supersedes: [Indy DIDComm-over-XMPP](https://github.com/Oskar-van-Deventer/indy-hipe/tree/master/text/didcom-over-xmpp) +- Supersedes: [Indy DIDComm-over-XMPP](https://github.com/Oskar-van-Deventer/indy-hipe/tree/main/text/didcom-over-xmpp) - Start Date: 2019-04-23 - Tags: [feature](/tags.md#feature) @@ -40,7 +40,7 @@ The DIDComm-over-XMPP feature provides an architecture for the transport of DIDC ### DIDComm -The DIDComm wire message format is specified in [HIPE 0028-wire-message-format](https://github.com/hyperledger/indy-hipe/tree/master/text/0028-wire-message-format). It can carry among others the DIDComm connection protocol, as specified in [Hyperledger Indy Hipe 0031](https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol). The purpose of the latter protocol is to set up a trusted electronic relationship between two parties (natural person, legal person, ...). Technically, the trust relationship involves the following +The DIDComm wire message format is specified in [HIPE 0028-wire-message-format](https://github.com/hyperledger/indy-hipe/tree/main/text/0028-wire-message-format). It can carry among others the DIDComm connection protocol, as specified in [Hyperledger Indy Hipe 0031](https://github.com/hyperledger/indy-hipe/tree/main/text/0031-connection-protocol). The purpose of the latter protocol is to set up a trusted electronic relationship between two parties (natural person, legal person, ...). Technically, the trust relationship involves the following - Univocal identification of the parties within the context of the relationship - Secure exchange of keys to encrypt and verify messages between agents of the parties @@ -128,7 +128,7 @@ The disadvantage of this method is that it creates a strong correlation point, w *Editor's note: More advantages or disadvantages?* -A typical application of Method 1 is when there is an ongoing human-to-human (or human-to-bot) chat session that uses XMPP and the two parties what to set up a pairwise DID relationship. One can skip Step 0 "Invitation to Connect" ([HIPE 0031](https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol)) and immediately perform Step 1 "Connection Request". +A typical application of Method 1 is when there is an ongoing human-to-human (or human-to-bot) chat session that uses XMPP and the two parties what to set up a pairwise DID relationship. One can skip Step 0 "Invitation to Connect" ([HIPE 0031](https://github.com/hyperledger/indy-hipe/tree/main/text/0031-connection-protocol)) and immediately perform Step 1 "Connection Request". **Method 2: Random userpart** diff --git a/features/0025-didcomm-transports/README.md b/features/0025-didcomm-transports/README.md index b88eaad63..336a7171d 100644 --- a/features/0025-didcomm-transports/README.md +++ b/features/0025-didcomm-transports/README.md @@ -58,7 +58,7 @@ XMPP is an effective transport for incoming DID-Communication messages directly - Independent of cloud agents and routing agents, as messages arrive directly at the mobile agent. - Well suited for direct consumer-to-consumer SSI transactions, from one mobile agent directly to another mobile agent without any DID-Communication intermediaries. - Simple encapsulation of DIDcom messages, getting trust from the DIDcom Encryption Envelope. -- Specified in [Aries RFC 0024: DIDCom-over-XMPP](https://github.com/hyperledger/aries-rfcs/tree/master/features/0024-didcomm-over-xmpp) +- Specified in [Aries RFC 0024: DIDCom-over-XMPP](https://github.com/hyperledger/aries-rfcs/tree/main/features/0024-didcomm-over-xmpp) #### Known Implementations diff --git a/features/0030-sync-connection/abandon-connection-protocol/README.md b/features/0030-sync-connection/abandon-connection-protocol/README.md index 8456a1512..b429daeaf 100644 --- a/features/0030-sync-connection/abandon-connection-protocol/README.md +++ b/features/0030-sync-connection/abandon-connection-protocol/README.md @@ -27,7 +27,7 @@ rules. ### Roles This is a [classic one-step notification]( -https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md#types-of-protocols), +https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/README.md#types-of-protocols), so it uses the predefined roles of `notifier` and `notified`. ![request-response pattern](../../../concepts/0003-protocols/notification.png) diff --git a/features/0042-lox/README.md b/features/0042-lox/README.md index 036b04e31..39296d164 100644 --- a/features/0042-lox/README.md +++ b/features/0042-lox/README.md @@ -50,7 +50,7 @@ Some systems back keyrings with hardware to increase security. The following flo ### Secure Enclaves Secure enclaves are used to describe HSMs, TPMs, and TEEs. -An explaination of how secure enclaves work is detailed [here](https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets#enclave-wrapping). +An explaination of how secure enclaves work is detailed [here](https://github.com/hyperledger/indy-hipe/tree/main/text/0013-wallets#enclave-wrapping). ### Details @@ -126,7 +126,7 @@ Trying to account for all of these will be difficult and may require changes to ## Prior art -A brief overview of enclaves and their services have been discussed in the [Indy wallet HIPE](https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets). +A brief overview of enclaves and their services have been discussed in the [Indy wallet HIPE](https://github.com/hyperledger/indy-hipe/tree/main/text/0013-wallets). ## Unresolved questions @@ -138,4 +138,4 @@ The following lists the implementations (if any) of this RFC. Please do a pull r Name / Link | Implementation Notes --- | --- -[Reference Code](https://github.com/hyperledger/aries-rfcs/tree/master/features/0042-lox/reference_code) | Example rust code that implements Lox using OS keychains +[Reference Code](https://github.com/hyperledger/aries-rfcs/tree/main/features/0042-lox/reference_code) | Example rust code that implements Lox using OS keychains diff --git a/features/0048-trust-ping/README.md b/features/0048-trust-ping/README.md index c608483bf..8eb948560 100644 --- a/features/0048-trust-ping/README.md +++ b/features/0048-trust-ping/README.md @@ -4,7 +4,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-02-01 - Status Note: Numerous implementations. -- Supersedes: [Indy HIPE 0032](https://github.com/hyperledger/indy-hipe/tree/master/text/0032-trust-ping) +- Supersedes: [Indy HIPE 0032](https://github.com/hyperledger/indy-hipe/tree/main/text/0032-trust-ping) - Start Date: 2018-12-11 - Tags: [feature](/tags.md#feature), [protocol](/tags.md#protocol), [test-anomaly](/tags.md#test-anomaly) @@ -110,7 +110,7 @@ messages are encrypted with suitable algorithms and keys. 2. Messages may be targeted at any known agent in the other party's sovereign domain, using [cross-domain routing conventions]( -https://github.com/hyperledger/indy-hipe/blob/master/text/0022-cross-domain-messaging/README.md), +https://github.com/hyperledger/indy-hipe/blob/main/text/0022-cross-domain-messaging/README.md), and may be encrypted and packaged to expose exactly and only the information desired, at each hop along the way. This allows two parties to evaluate the completeness of diff --git a/features/0116-evidence-exchange/README.md b/features/0116-evidence-exchange/README.md index 4f96b9d70..f477f50a2 100644 --- a/features/0116-evidence-exchange/README.md +++ b/features/0116-evidence-exchange/README.md @@ -13,7 +13,7 @@ The goal of this protocol is to allow Holders to provider an inquiring Verifier ## Motivation -During the identity verification process, an entity *may* require access to the genesis documents used to establish digital credentials issued by a credential issuing entity or [Credential Service Provider (CSP)](./eep_glossary.md). In support of the transition from existing business verification processes to emerging business processes that rely on digitally verified credentials using protocols such as [0036-issue-credential](https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential) and [0037-present-proof](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof), we need to establish a protocol that allow entities to make this transition while remaining compliant with business and regulatory requirements. Therefore, **we need a mechanism for Verifiers to obtain access to vetted evidence (physical or digital information or documentation) without requiring a relationship or interaction with the Issuer**. +During the identity verification process, an entity *may* require access to the genesis documents used to establish digital credentials issued by a credential issuing entity or [Credential Service Provider (CSP)](./eep_glossary.md). In support of the transition from existing business verification processes to emerging business processes that rely on digitally verified credentials using protocols such as [0036-issue-credential](https://github.com/hyperledger/aries-rfcs/tree/main/features/0036-issue-credential) and [0037-present-proof](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof), we need to establish a protocol that allow entities to make this transition while remaining compliant with business and regulatory requirements. Therefore, **we need a mechanism for Verifiers to obtain access to vetted evidence (physical or digital information or documentation) without requiring a relationship or interaction with the Issuer**. >While this protocol *should* be supported by all persona, its relevance to decentralized identity ecosystems is highly dependent on the business policies of a market segment of Verifiers. For more details see the [Persona](#persona) section. @@ -180,7 +180,7 @@ These forms of *Identity Evidence* are examples of trusted credentials that an E ## Tutorial -The evidence exchange protocol builds on the attachment decorator within DIDComm using the the [Inlining Method](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#inlining) for *Digital Assertions* and the [Appending Method](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#appending) for *Original Documents*. +The evidence exchange protocol builds on the attachment decorator within DIDComm using the the [Inlining Method](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#inlining) for *Digital Assertions* and the [Appending Method](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#appending) for *Original Documents*. The protocol is comprised of the following messages and associated actions: @@ -195,7 +195,7 @@ The protocol is comprised of the following messages and associated actions: ### Request Evidence Message -This message should be used as an accompaniment to an [issue credential message](https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential#issue-credential). Upon receipt and storage of a credential the Holder should compose an ```evidence_request``` for each credential received from the Issuer. The Holder may use this message to get an update for new and existing credentials from the Issuer. +This message should be used as an accompaniment to an [issue credential message](https://github.com/hyperledger/aries-rfcs/tree/main/features/0036-issue-credential#issue-credential). Upon receipt and storage of a credential the Holder should compose an ```evidence_request``` for each credential received from the Issuer. The Holder may use this message to get an update for new and existing credentials from the Issuer. ```json { @@ -345,7 +345,7 @@ Description of attributes: } ``` -This message adheres to the attribute [content formats outlined in the Aries Attachments RFC ](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#base64) with the following additions: +This message adheres to the attribute [content formats outlined in the Aries Attachments RFC ](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#base64) with the following additions: * `mime-type`: Describes the MIME type of the attached content. Optional but recommended. * `filename`: A hint about the name that might be used if this attachment is persisted as a file. It is not required, and need not be unique. If this field is present and mime-type is not, the extension on the filename may be used to infer a MIME type. @@ -424,7 +424,7 @@ This message adheres to the attribute [content formats outlined in the Aries Att } ``` -This message adheres to the attribute [content formats outlined in the Aries Attachments RFC ](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#base64) and builds on the [By Value Attachments](#by-value-attachments) with the following additions: +This message adheres to the attribute [content formats outlined in the Aries Attachments RFC ](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#base64) and builds on the [By Value Attachments](#by-value-attachments) with the following additions: * `links`: A list of zero or more locations at which the content may be fetched. * `url`: Link to the external document. @@ -434,7 +434,7 @@ Upon completion of the Evidence Request and Response exchange, the Holder's Agen ### Evidence Access Request Message -Upon the successful processing of a [credential proof presentation message](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof#presentation), a Verifier may desire to request supporting evidence for the processed credential. This ```evidence_access_request``` message is built by the Verifier and sent to the Holder's agent. Similar to the ```request_evidence``` message, the Verifier may use this message to get an update for new and existing credentials associated with the Holder. The intent of this message is for the Verifier to establish trust by obtaining a copy of the available evidence and performing the necessary content validation. +Upon the successful processing of a [credential proof presentation message](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof#presentation), a Verifier may desire to request supporting evidence for the processed credential. This ```evidence_access_request``` message is built by the Verifier and sent to the Holder's agent. Similar to the ```request_evidence``` message, the Verifier may use this message to get an update for new and existing credentials associated with the Holder. The intent of this message is for the Verifier to establish trust by obtaining a copy of the available evidence and performing the necessary content validation. ```json { @@ -457,7 +457,7 @@ Description of attributes: ![verify-workflow](./img/verify_cred_flow.png) -This protocol is intended to be flexible and applicable to a variety of use cases. While our discussion has circulated around the use of the protocol as follow-up to the processing of a credential proof presentment flow, the fact is that the protocol can be used at any point after a Pair-wise DID Exchange has been successfully established and is therefore in the [complete state](https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange#complete) as defined by the DID Exchange Protocol. An `IssuerDID` (or DID of the an entity that is one of the two parties in a private pair-wise relationship) is assumed to be known under all possible conditions once the relationship is in the complete state. +This protocol is intended to be flexible and applicable to a variety of use cases. While our discussion has circulated around the use of the protocol as follow-up to the processing of a credential proof presentment flow, the fact is that the protocol can be used at any point after a Pair-wise DID Exchange has been successfully established and is therefore in the [complete state](https://github.com/hyperledger/aries-rfcs/tree/main/features/0023-did-exchange#complete) as defined by the DID Exchange Protocol. An `IssuerDID` (or DID of the an entity that is one of the two parties in a private pair-wise relationship) is assumed to be known under all possible conditions once the relationship is in the complete state. ### Evidence Access Response Message @@ -492,7 +492,7 @@ This message is required for a Holder Agent in response to an ```evidence_access } ``` -This message adheres to the attribute [content formats outlined in the Aries Attachments RFC ](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#base64) and leverages the same [Evidence Response Message](#evidence-response-message) attribute descriptions. +This message adheres to the attribute [content formats outlined in the Aries Attachments RFC ](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md#base64) and leverages the same [Evidence Response Message](#evidence-response-message) attribute descriptions. ## Reference @@ -517,7 +517,7 @@ As noted in the [references](#reference) section, there are a number of trending ## Prior art -This protocol builds on the foundational capabilities of DIDComm messages, most notable being the [attachment decorator](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md) within DIDComm. +This protocol builds on the foundational capabilities of DIDComm messages, most notable being the [attachment decorator](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0017-attachments/README.md) within DIDComm. ## Unresolved questions diff --git a/features/0124-did-resolution-protocol/README.md b/features/0124-did-resolution-protocol/README.md index 535286c7a..bfb98b9cd 100644 --- a/features/0124-did-resolution-protocol/README.md +++ b/features/0124-did-resolution-protocol/README.md @@ -16,10 +16,10 @@ to resolve DIDs and dereference DID URLs. ## Motivation DID Resolution is an important feature of Aries. It is a prerequisite for the `unpack()` function in -[DIDComm](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm), especially in +[DIDComm](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0005-didcomm), especially in [Cross-Domain Messaging](../../concepts/0094-cross-domain-messaging/README.md), since cryptographic keys must be discovered from DIDs in order to enable trusted communication between the -[agents](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents) associated with DIDs. +[agents](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0004-agents) associated with DIDs. DID Resolution is also required for other operations, e.g. for verifying credentials or for discovering [DIDComm service endpoints](../../features/0067-didcomm-diddoc-conventions/README.md). @@ -43,7 +43,7 @@ invokes another DID Resolver via a "remote" binding (such as HTTP(S) or DIDComm) ### Name and Version This defines the `did_resolution` protocol, version 0.1, as identified by the -following [PIURI](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/uris.md#piuri): +following [PIURI](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/uris.md#piuri): https://didcomm.org/did_resolution/0.1 diff --git a/features/0160-connection-protocol/README.md b/features/0160-connection-protocol/README.md index 0eed6dcea..39ce74196 100644 --- a/features/0160-connection-protocol/README.md +++ b/features/0160-connection-protocol/README.md @@ -3,7 +3,7 @@ - Status: [ACCEPTED](/README.md#accepted) - Since: 2019-08-06 - Status Note: This is the protocol with existing uses. It is expected that [RFC 0023 DID Exchange](../../features/0023-did-exchange/README.md) will replace this protocol. -- Supersedes: [HIPE 0031 - Connection Protocol](https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol) +- Supersedes: [HIPE 0031 - Connection Protocol](https://github.com/hyperledger/indy-hipe/tree/main/text/0031-connection-protocol) - Start Date: 2018-06-29 - Tags: [feature](/tags.md#feature), [protocol](/tags.md#protocol), [test-anomaly](/tags.md#test-anomaly) diff --git a/features/0183-revocation-notification/README.md b/features/0183-revocation-notification/README.md index 8d949404d..76910410f 100644 --- a/features/0183-revocation-notification/README.md +++ b/features/0183-revocation-notification/README.md @@ -50,17 +50,17 @@ The `revoke` message sent by the `issuer` to the `holder` is as follows: Description of fields: -* `~please_ack` (optional) -- as described by the [Please ACK Decorator RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0317-please-ack). If `OUTCOME` is specified, the `holder` should send an ack when the holder's agent has successfully notified the holder of the revocation. +* `~please_ack` (optional) -- as described by the [Please ACK Decorator RFC](https://github.com/hyperledger/aries-rfcs/tree/main/features/0317-please-ack). If `OUTCOME` is specified, the `holder` should send an ack when the holder's agent has successfully notified the holder of the revocation. -* `thread_id` (required) -- the [thread ID](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading#thread-id-thid) of the [issue-credential-v2](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2) protocol which was used to issue one or more credentials that have been revoked by the issuer. If multiple credentials were issued, each credential has a different credential format but contains the same claims as described [here](https://github.com/hyperledger/aries-rfcs/tree/b982c24b9083dd5dddff6343dbf534cd1cfe36a6/features/0453-issue-credential-v2#message-attachments); therefore, this message notifies the holder that all of these credentials have been revoked. +* `thread_id` (required) -- the [thread ID](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0008-message-id-and-threading#thread-id-thid) of the [issue-credential-v2](https://github.com/hyperledger/aries-rfcs/tree/main/features/0453-issue-credential-v2) protocol which was used to issue one or more credentials that have been revoked by the issuer. If multiple credentials were issued, each credential has a different credential format but contains the same claims as described [here](https://github.com/hyperledger/aries-rfcs/tree/b982c24b9083dd5dddff6343dbf534cd1cfe36a6/features/0453-issue-credential-v2#message-attachments); therefore, this message notifies the holder that all of these credentials have been revoked. * `comment` (optional) -- a field that provides some human readable information about the revocation notification. This is typically the reason for the revocation as deemed appropriate by the issuer. ## Reference -* See the [issue-credential-v2](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2) protocol. -* See the [thread ID](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading#thread-id-thid) description. -* See the [Please ACK Decorator RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0317-please-ack). +* See the [issue-credential-v2](https://github.com/hyperledger/aries-rfcs/tree/main/features/0453-issue-credential-v2) protocol. +* See the [thread ID](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0008-message-id-and-threading#thread-id-thid) description. +* See the [Please ACK Decorator RFC](https://github.com/hyperledger/aries-rfcs/tree/main/features/0317-please-ack). ## Drawbacks diff --git a/features/0193-coin-flip/README.md b/features/0193-coin-flip/README.md index a7eda39cf..49f70dd46 100644 --- a/features/0193-coin-flip/README.md +++ b/features/0193-coin-flip/README.md @@ -20,7 +20,7 @@ To guarantee fairness, it is often important to pick one party in a protocol to ### Name and Version This defines the `coinflip` protocol, version 1.x, as identified by the -following [PIURI](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/uris.md#piuri): +following [PIURI](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/uris.md#piuri): https://github.com/hyperledger/aries-rfcs/features/0193-coin-flip/1.0 diff --git a/features/0214-help-me-discover/README.md b/features/0214-help-me-discover/README.md index 299e87b01..e59fbe6f7 100644 --- a/features/0214-help-me-discover/README.md +++ b/features/0214-help-me-discover/README.md @@ -43,7 +43,7 @@ The following requirements do not change this simple framework, but they introdu * It is desirable that criteria should be expressed in a way that harmonizes with proof requests, which also need a criteria language. * It must be possible for the responder to give partial answers: "I do know a good mechanic, but not one that lives close to you." * It must be possible for the responder to give compound answers: "Here's an item that satisfies critiera 1 and 3, and here's a different itme that satisfies criteria 2 and 4." -* It must be possible for this protocol to precede another protocol (e.g., [RFC 0028 Introduce Protocol](https://github.com/hyperledger/aries-rfcs/blob/master/features/0028-introduce/README.md)) in such a way that what follows can refer back to items in this protocol in an unambiguous way, as in "Here's an introduction to the party that I just told you about, that satisfies criteria 3 and 4 from the 'Help Me Discover' request you recently made." +* It must be possible for this protocol to precede another protocol (e.g., [RFC 0028 Introduce Protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0028-introduce/README.md)) in such a way that what follows can refer back to items in this protocol in an unambiguous way, as in "Here's an introduction to the party that I just told you about, that satisfies criteria 3 and 4 from the 'Help Me Discover' request you recently made." ### Messages diff --git a/features/0249-rich-schema-contexts/README.md b/features/0249-rich-schema-contexts/README.md index 04bf8ca33..46ec918d3 100644 --- a/features/0249-rich-schema-contexts/README.md +++ b/features/0249-rich-schema-contexts/README.md @@ -16,7 +16,7 @@ meaning among rich schema objects. Context objects are processed in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common). ## Motivation [motivation]: #motivation @@ -62,11 +62,11 @@ Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger). `@context` will be written to the ledger in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). ### Aries Data Registry Interface Aries Data Registry Interface methods for adding and retrieving `@context` from the -ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#aries-data-registry-interface). +ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#aries-data-registry-interface). This means the following methods can be used: - `write_rich_schema_object` @@ -84,8 +84,8 @@ More information on `@context` from the JSON-LD specification may be found [here](https://w3c.github.io/json-ld-syntax/#the-context) and [here](https://w3c.github.io/json-ld-syntax/#advanced-context-usage). -- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) +- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) ## Drawbacks diff --git a/features/0281-rich-schemas/README.md b/features/0281-rich-schemas/README.md index 1a0413c0f..b14c3e034 100644 --- a/features/0281-rich-schemas/README.md +++ b/features/0281-rich-schemas/README.md @@ -19,7 +19,7 @@ additional properties. For example a schema for "employee" may inherit from the schema for "person." Schema objects are processed in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common). ## Motivation [motivation]: #motivation @@ -101,13 +101,13 @@ Schema, OWL, etc. ### Properties Rich Schema properties follow the generic template defined in -[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). Rich Schema's `content` field is a JSON-LD-serialized string with the following fields: #### @id A rich schema must have an `@id` property. The value of this property must -be equal to the `id` field which is a DID (see [Identification of Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#identification-of-rich-schema-objects)). +be equal to the `id` field which is a DID (see [Identification of Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#identification-of-rich-schema-objects)). A [rich schema](README.md) may refer to the `@id` of another rich schema to define a parent schema. A property of a rich schema may use the `@id` of @@ -227,12 +227,12 @@ Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger). A Schema will be written to the ledger in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). ### Aries Data Registry Interface Aries Data Registry Interface methods for adding and retrieving a Schema from the -ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#aries-data-registry-interface). +ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#aries-data-registry-interface). This means the following methods can be used: - `write_rich_schema_object` @@ -245,8 +245,8 @@ This means the following methods can be used: More information on the Verifiable Credential data model use of `schemas` may be found [here](https://w3c.github.io/vc-data-model/#data-schemas). -- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) +- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) ## Drawbacks diff --git a/features/0334-jwe-envelope/README.md b/features/0334-jwe-envelope/README.md index 30962bb6d..76e43bde5 100644 --- a/features/0334-jwe-envelope/README.md +++ b/features/0334-jwe-envelope/README.md @@ -125,7 +125,7 @@ Another prior effort towards enhancing JWE compliance is to use XChacha20Poly130 } ``` -`typ` header field is the DIDComm Transports value as mentioned in [RFC-0025](https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports#reference). This RFC states the prefix `application/` but according to [IANA Media types](https://www.iana.org/assignments/media-types/media-types.xhtml#application) the prefix is implied therefore not needed here. +`typ` header field is the DIDComm Transports value as mentioned in [RFC-0025](https://github.com/hyperledger/aries-rfcs/tree/main/features/0025-didcomm-transports#reference). This RFC states the prefix `application/` but according to [IANA Media types](https://www.iana.org/assignments/media-types/media-types.xhtml#application) the prefix is implied therefore not needed here. ### Anoncrypt using ECDH-ES key wrapping mode and A256GCM content encryption @@ -205,7 +205,7 @@ See concrete [anoncrypt](anoncrypt-examples.md) and [authcrypt](authcrypt-exampl ## JWE detached mode nested envelopes -There are situations in DIDComm messaging where an envelope could be nested inside another envelope -- particularly [RFC 46: Mediators and Relays](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0046-mediators-and-relays). Normally nesting envelopes implies that the envelope payloads will incur additional encryption and encoding operations at each parent level in the nesting. This section describes a mechanism to extract the nested payloads outside the nesting structure to avoid these additional operations. +There are situations in DIDComm messaging where an envelope could be nested inside another envelope -- particularly [RFC 46: Mediators and Relays](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0046-mediators-and-relays). Normally nesting envelopes implies that the envelope payloads will incur additional encryption and encoding operations at each parent level in the nesting. This section describes a mechanism to extract the nested payloads outside the nesting structure to avoid these additional operations. ### Detached mode @@ -289,8 +289,8 @@ This illustration extends the serialization shown in [RFC 7516](https://tools.ie ## Prior art - The [JWE](https://tools.ietf.org/html/rfc7518) family of encryption methods. -- [Aries RFC 0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope) suggested envelope formats will be superseded by this RFC. -- [Aries RFC 0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports#reference) for the content type used in the proposed envelopes. +- [Aries RFC 0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/main/features/0019-encryption-envelope) suggested envelope formats will be superseded by this RFC. +- [Aries RFC 0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/main/features/0025-didcomm-transports#reference) for the content type used in the proposed envelopes. - [minimal-cipher](https://github.com/digitalbazaar/minimal-cipher) implementation - [Aries-Framework-Go](https://github.com/hyperledger/aries-framework-go/) has an experimental (X)Chacha20Poly1305 Packer implementation based on Aries-RFCs [issue-133](https://github.com/hyperledger/aries-rfcs/issues/133#issuecomment-535199768) - [IANA Media Types](https://www.iana.org/assignments/media-types/media-types.xhtml#application) diff --git a/features/0347-proof-negotiation/README.md b/features/0347-proof-negotiation/README.md index 56fcf5bbc..5bca2e518 100644 --- a/features/0347-proof-negotiation/README.md +++ b/features/0347-proof-negotiation/README.md @@ -10,7 +10,7 @@ ## Summary -This RFC proposes an extension to [Aries RFC 0037: Present Proof Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof#aries-rfc-0037-present-proof-protocol-10) by taking the concept of groups out of the [DID credential manifest](https://github.com/decentralized-identity/credential-manifest/blob/master/explainer.md) and including them in the present proof protocol. Additionally to the rules described in the credential manifest, an option to provide alternative attributes with a weight is being introduced here. Also, the possibility to include not only attributes, but also credentials and openids in a proof by using a "type" was taken from the DID credential manifest. +This RFC proposes an extension to [Aries RFC 0037: Present Proof Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof#aries-rfc-0037-present-proof-protocol-10) by taking the concept of groups out of the [DID credential manifest](https://github.com/decentralized-identity/credential-manifest/blob/master/explainer.md) and including them in the present proof protocol. Additionally to the rules described in the credential manifest, an option to provide alternative attributes with a weight is being introduced here. Also, the possibility to include not only attributes, but also credentials and openids in a proof by using a "type" was taken from the DID credential manifest. The goal of this is an approach to make proof presentation more flexible, allowing attributes to be required or optional as well as allowing a choose-from-a-list scenario. So far, proof requests were to be replied to with a proof response that contained all attributes listed in the proof request. To this, this RFC adds a way to mark attributes as optional, so that they are communicated as nice-to-have to the user of a wallet. @@ -269,7 +269,7 @@ The base64url-encoded content above would decode to this data: ``` ## Reference -The "@id"-Tag and thread decorator in the above JSON-messages is taken from [RFC 0008](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0008-message-id-and-threading). +The "@id"-Tag and thread decorator in the above JSON-messages is taken from [RFC 0008](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0008-message-id-and-threading). ## Drawbacks @@ -282,7 +282,7 @@ An alternative way of implementing the proof negotiation is performing it ahead The problem with not implementing this feature would be that a proof request may need to be repeated over and over again with a different list of requested attributes each time, until a list is transferred which the specific user can reply to. This process would be unnecessarily complicated and can be facilitated by implementing this here concept. ## Prior art -[RFC0037-present-proof](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof) is the foundation which this RFC builds on using groups from the [credential manifest](https://github.com/decentralized-identity/credential-manifest) by +[RFC0037-present-proof](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof) is the foundation which this RFC builds on using groups from the [credential manifest](https://github.com/decentralized-identity/credential-manifest) by the decentralized identity foundation, a "format that normalizes the definition of requirements for the issuance of a credential". ## Unresolved questions diff --git a/features/0360-use-did-key/README.md b/features/0360-use-did-key/README.md index 76d30de03..c927fe001 100644 --- a/features/0360-use-did-key/README.md +++ b/features/0360-use-did-key/README.md @@ -27,7 +27,7 @@ Note that simply knowing the key type is not necessarily sufficient to be able t ## Tutorial -An example of the use of the replacement of a verkey with `did:key` can be found in the [~service decorator RFC](https://github.com/hyperledger/aries-rfcs/tree/master/features/0056-service-decorator). Notably in the example at the beginning of the [tutorial](https://github.com/hyperledger/aries-rfcs/tree/master/features/0056-service-decorator#tutorial) section, the verkeys in the `recipientKeys` and `routingKeys` items would be changed from native keys to use `did:key` as follows: +An example of the use of the replacement of a verkey with `did:key` can be found in the [~service decorator RFC](https://github.com/hyperledger/aries-rfcs/tree/main/features/0056-service-decorator). Notably in the example at the beginning of the [tutorial](https://github.com/hyperledger/aries-rfcs/tree/main/features/0056-service-decorator#tutorial) section, the verkeys in the `recipientKeys` and `routingKeys` items would be changed from native keys to use `did:key` as follows: ``` jsonc { @@ -57,17 +57,17 @@ The `did:key` method uses the strings that are the DID, public key and key type The following currently implemented RFCs would be affected by acceptance of this RFC. In these RFCs, the JSON items that currently contain naked public keys (mostly the items `recipientKeys` and `routingKeys`) would be changed to use `did:key` references where applicable. Note that in these items public DIDs could also be used if applicable for a given use case. -- [0023-did-exchange](https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange) - Invitation Message -- [0028-introduce](https://github.com/hyperledger/aries-rfcs/tree/master/features/0028-introduce) -- [0056-service-decorator](https://github.com/hyperledger/aries-rfcs/tree/master/features/0056-service-decorator) -- [0160-connection-protocol](https://github.com/hyperledger/aries-rfcs/tree/master/features/0160-connection-protocol) -- [0434-out-of-band-protocols](https://github.com/hyperledger/aries-rfcs/blob/master/features/0434-outofband/README.md) -- [0211-mediator-coordination-protocol](https://github.com/hyperledger/aries-rfcs/blob/master/features/0211-route-coordination/README.md) +- [0023-did-exchange](https://github.com/hyperledger/aries-rfcs/tree/main/features/0023-did-exchange) - Invitation Message +- [0028-introduce](https://github.com/hyperledger/aries-rfcs/tree/main/features/0028-introduce) +- [0056-service-decorator](https://github.com/hyperledger/aries-rfcs/tree/main/features/0056-service-decorator) +- [0160-connection-protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0160-connection-protocol) +- [0434-out-of-band-protocols](https://github.com/hyperledger/aries-rfcs/blob/main/features/0434-outofband/README.md) +- [0211-mediator-coordination-protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0211-route-coordination/README.md) Service entries in `did:peer` DIDDocs (such as in RFCs -[0094-cross-domain-messaging](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging) +[0094-cross-domain-messaging](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0094-cross-domain-messaging) and -[0067-didcomm-diddoc-conventions](https://github.com/hyperledger/aries-rfcs/tree/master/features/0067-didcomm-diddoc-conventions)) +[0067-didcomm-diddoc-conventions](https://github.com/hyperledger/aries-rfcs/tree/main/features/0067-didcomm-diddoc-conventions)) should **NOT** use a `did:key` public key representation. Instead, service entries in the DIDDoc should reference keys defined internally in the DIDDoc where appropriate. diff --git a/features/0418-rich-schema-encoding/README.md b/features/0418-rich-schema-encoding/README.md index 1cc6d4d9e..98cd5e14f 100644 --- a/features/0418-rich-schema-encoding/README.md +++ b/features/0418-rich-schema-encoding/README.md @@ -25,7 +25,7 @@ and avoid hashed values as much as possible, as they do not support predicate proofs. Encoding objects are processed in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common). ## Motivation @@ -58,7 +58,7 @@ is stored on the ledger. ### Properties Encoding's properties follow the generic template defined in -[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). Encoding's `content` field is a JSON-serialized string with the following fields: @@ -181,12 +181,12 @@ Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger). An Encoding object will be written to the ledger in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). ### Aries Data Registry Interface Aries Data Registry Interface methods for adding and retrieving an Encoding object from the -ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#aries-data-registry-interface). +ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#aries-data-registry-interface). This means the following methods can be used: - `write_rich_schema_object` @@ -201,8 +201,8 @@ The following is a [Here](https://www.researchgate.net/publication/220922101_A_Signature_Scheme_with_Efficient_Protocols) is the paper that defines Camenisch-Lysyanskaya signatures. -- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) +- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) ## Drawbacks diff --git a/features/0428-prepare-issue-rich-credential/README.md b/features/0428-prepare-issue-rich-credential/README.md index 42cea3b38..af09b64c2 100644 --- a/features/0428-prepare-issue-rich-credential/README.md +++ b/features/0428-prepare-issue-rich-credential/README.md @@ -44,7 +44,7 @@ use is already present. definition refers to the issuer DID. 1. Using the credential definition, mapping, and schema(s) issue to the holder a credential based on the credential definition and the supplied claim data. The -[Issue Credential Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential) +[Issue Credential Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0036-issue-credential) will be the model for another RFC containing minor modifications to issue a credential using the new rich schema objects. @@ -54,13 +54,13 @@ Subsequent credentials may be issued by repeating only the last step. ## Reference -- [RFC 0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [RFC 0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) -- [RFC 0249: Aries Rich Schema Contexts](https://github.com/hyperledger/aries-rfcs/tree/master/features/0249-rich-schema-contexts) -- [RFC 0281: Aries Rich Schemas](https://github.com/hyperledger/aries-rfcs/tree/master/features/0281-rich-schemas) -- [RFC XXXX: Aries Rich Schema Mappings](https://github.com/hyperledger/aries-rfcs/tree/master/features/XXXX-rich-schema-mappings) -- [RFC XXXX: Aries Rich Schema Credential Definitions](https://github.com/hyperledger/aries-rfcs/tree/master/features/XXXX-rich-schema-cred-defs) -- [RFC 0036: Issue Credential Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential) +- [RFC 0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [RFC 0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) +- [RFC 0249: Aries Rich Schema Contexts](https://github.com/hyperledger/aries-rfcs/tree/main/features/0249-rich-schema-contexts) +- [RFC 0281: Aries Rich Schemas](https://github.com/hyperledger/aries-rfcs/tree/main/features/0281-rich-schemas) +- [RFC XXXX: Aries Rich Schema Mappings](https://github.com/hyperledger/aries-rfcs/tree/main/features/XXXX-rich-schema-mappings) +- [RFC XXXX: Aries Rich Schema Credential Definitions](https://github.com/hyperledger/aries-rfcs/tree/main/features/XXXX-rich-schema-cred-defs) +- [RFC 0036: Issue Credential Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0036-issue-credential) diff --git a/features/0429-prepare-req-rich-pres/README.md b/features/0429-prepare-req-rich-pres/README.md index e8481fe56..558e55dcf 100644 --- a/features/0429-prepare-req-rich-pres/README.md +++ b/features/0429-prepare-req-rich-pres/README.md @@ -30,7 +30,7 @@ rules. Presentation definitions specify desired attributes and predicates). the verifiable data registry. (Anchoring the presentation definition to the verifiable data registry allows other verifiers to easily use it. It can be done by writing the full presentation definition's content to the ledger, or just writing a digital fingerprint/hash of the content.) 1. Using the presentation definition, request a presentation from the holder. -The [Present Proof Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof) +The [Present Proof Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof) will be the model for another RFC containing minor modifications for presenting a proof based on verifiable credentials using the new rich schema objects. @@ -38,10 +38,10 @@ a proof based on verifiable credentials using the new rich schema objects. ## Reference -- [RFC 0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [RFC 0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) -- [RFC XXXX: Aries Rich Schema Presentation Definitions](https://github.com/hyperledger/aries-rfcs/tree/master/features/XXXX-rich-schema-pres-defs) -- [RFC 0037: Present Proof Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof) +- [RFC 0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [RFC 0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) +- [RFC XXXX: Aries Rich Schema Presentation Definitions](https://github.com/hyperledger/aries-rfcs/tree/main/features/XXXX-rich-schema-pres-defs) +- [RFC 0037: Present Proof Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof) diff --git a/features/0434-outofband/README.md b/features/0434-outofband/README.md index 5c8fe7949..7b33d2306 100644 --- a/features/0434-outofband/README.md +++ b/features/0434-outofband/README.md @@ -248,13 +248,13 @@ The processing rules for the `services` block are: The attributes in the inline form parallel the attributes of a DID Document for increased meaning. The `recipientKeys` and `routingKeys` within the inline block decorator **MUST** be [`did:key` references](https://digitalbazaar.github.io/did-method-key/). -As defined in the [DIDComm Cross Domain Messaging RFC](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging), if `routingKeys` is present and non-empty, additional forwarding wrapping are necessary in the response message. +As defined in the [DIDComm Cross Domain Messaging RFC](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0094-cross-domain-messaging), if `routingKeys` is present and non-empty, additional forwarding wrapping are necessary in the response message. When considering routing and options for out-of-band messages, keep in mind that the more detail in the message, the longer the URL will be and (if used) the more dense (and harder to scan) the QR code will be. ##### Service Endpoint -The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the `serviceEndpoint` in the DIDDoc of the resolved DID **MUST** be a URI, and the `recipientKeys` **MUST** contain a single key. That key is appended to the end of the list of `routingKeys` for processing. For more information about message forwarding and routing, see [RFC 0094 Cross Domain Messaging](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0094-cross-domain-messaging). +The service endpoint used to transmit the response is either present in the out-of-band message or available in the DID Document of a presented DID. If the endpoint is itself a DID, the `serviceEndpoint` in the DIDDoc of the resolved DID **MUST** be a URI, and the `recipientKeys` **MUST** contain a single key. That key is appended to the end of the list of `routingKeys` for processing. For more information about message forwarding and routing, see [RFC 0094 Cross Domain Messaging](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0094-cross-domain-messaging). ### Adoption Messages @@ -332,7 +332,7 @@ There is an optional courtesy error message stemming from an out-of-band message } ``` -See the [problem-report](https://github.com/hyperledger/aries-rfcs/tree/master/features/0035-report-problem) protocol for details on the items in the example. +See the [problem-report](https://github.com/hyperledger/aries-rfcs/tree/main/features/0035-report-problem) protocol for details on the items in the example. ### Flow Overview @@ -524,7 +524,7 @@ If the receiver included a [`~service` decorator](../0056-service-decorator/READ ## Prior art - The out-of-band message/response process is similar to other key exchange protocols. -- The [Connections](https://github.com/hyperledger/aries-rfcs/tree/master/features/0160-connection-protocol) and [DID Exchange](https://github.com/hyperledger/aries-rfcs/tree/master/features/0023-did-exchange) protocols have (or had) their own `invitation` method. +- The [Connections](https://github.com/hyperledger/aries-rfcs/tree/main/features/0160-connection-protocol) and [DID Exchange](https://github.com/hyperledger/aries-rfcs/tree/main/features/0023-did-exchange) protocols have (or had) their own `invitation` method. - The `~service` decorator in combination with a request/response-type protocol message (such as present-proof/request) has previously used in place of the out-of-band `request` message. ## Unresolved questions diff --git a/features/0445-rich-schema-mapping/README.md b/features/0445-rich-schema-mapping/README.md index a0e2e318f..bb4640077 100644 --- a/features/0445-rich-schema-mapping/README.md +++ b/features/0445-rich-schema-mapping/README.md @@ -16,7 +16,7 @@ claim in a mapping has a reference to an encoding, and those encodings are defined in encoding objects. Mapping objects are processed in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common). ## Motivation @@ -78,13 +78,13 @@ mapping object may need to be defined. ### Properties Mapping's properties follow the generic template defined in -[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). Mapping's `content` field is a JSON-LD-serialized string with the following fields: #### @id A Mapping must have an `@id` property. The value of this property must -be equal to the `id` field which is a DID (see [Identification of Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#identification-of-rich-schema-objects)). +be equal to the `id` field which is a DID (see [Identification of Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#identification-of-rich-schema-objects)). #### @type A Mapping must have a `@type` property. The value of this property must @@ -209,12 +209,12 @@ Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger). A Mapping object will be written to the ledger in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). ### Aries Data Registry Interface Aries Data Registry Interface methods for adding and retrieving a Mapping object from the -ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#aries-data-registry-interface). +ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#aries-data-registry-interface). This means the following methods can be used: - `write_rich_schema_object` @@ -229,8 +229,8 @@ The following is a [Here](https://www.researchgate.net/publication/220922101_A_Signature_Scheme_with_Efficient_Protocols) is the paper that defines Camenisch-Lysyanskaya signatures. -- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) +- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) - [W3C verifiable credential specification](https://www.w3.org/TR/vc-data-model) ## Drawbacks diff --git a/features/0446-rich-schema-cred-def/README.md b/features/0446-rich-schema-cred-def/README.md index edb959c55..6aeab7609 100644 --- a/features/0446-rich-schema-cred-def/README.md +++ b/features/0446-rich-schema-cred-def/README.md @@ -16,7 +16,7 @@ The public keys can be used for signing the credentials by the Issuer according defined by the referenced Mapping. Credential Definition objects are processed in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common). ## Motivation @@ -52,7 +52,7 @@ credentials issued for this key. ### Properties Credential definition's properties follow the generic template defined in -[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). Credential Definition's `content` field is a JSON-serialized string with the following fields: @@ -93,12 +93,12 @@ Aries will provide a means for writing contexts to and reading contexts from a verifiable data registry (such as a distributed ledger). A Credential Definition object will be written to the ledger in a generic way defined in -[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). +[Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#how-rich-schema-objects-are-stored-in-the-data-registry). ### Aries Data Registry Interface Aries Data Registry Interface methods for adding and retrieving a Credential Definition object from the -ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common#aries-data-registry-interface). +ledger comply with the generic approach described in [Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common#aries-data-registry-interface). This means the following methods can be used: - `write_rich_schema_object` @@ -113,8 +113,8 @@ The following is a [Here](https://www.researchgate.net/publication/220922101_A_Signature_Scheme_with_Efficient_Protocols) is the paper that defines Camenisch-Lysyanskaya signatures. -- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) -- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0420-rich-schemas-common) +- [0250: Rich Schema Objects](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) +- [0420: Rich Schema Objects Common](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0420-rich-schemas-common) ## Drawbacks diff --git a/features/0509-action-menu/README.md b/features/0509-action-menu/README.md index cf60be941..2cd2207b8 100644 --- a/features/0509-action-menu/README.md +++ b/features/0509-action-menu/README.md @@ -197,8 +197,8 @@ N/A There are several existing RFCs that relate to the general problem of "Discovery" -* [Aries RFC 0031 : Discover Features Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0031-discover-features) -- This RFC provides _Aries Protocol_ discovery between two Agents but no direction on user interface display or action handling. -* [Aries RFC 0214 : "Help Me Discover" Protocol](https://github.com/hyperledger/aries-rfcs/tree/master/features/0214-help-me-discover) -- This RFC introduces the concept of a query language protocol between agents to obtain "referal" to a third agent. +* [Aries RFC 0031 : Discover Features Protocol 1.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0031-discover-features) -- This RFC provides _Aries Protocol_ discovery between two Agents but no direction on user interface display or action handling. +* [Aries RFC 0214 : "Help Me Discover" Protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0214-help-me-discover) -- This RFC introduces the concept of a query language protocol between agents to obtain "referal" to a third agent. ## Unresolved questions diff --git a/features/0587-encryption-envelope-v2/README.md b/features/0587-encryption-envelope-v2/README.md index 1e39e0d9e..adc3b5015 100644 --- a/features/0587-encryption-envelope-v2/README.md +++ b/features/0587-encryption-envelope-v2/README.md @@ -15,7 +15,7 @@ This RFC proposes that we support the definition of envelopes from [DIDComm Mess ## Motivation This RFC defines ciphersuites for envelopes such that we can achieve better compatability with DIDComm Messaging being specified at DIF. -The ciphersuites defined in this RFC are a subset of the definitions in [Aries RFC 0334-jwe-envelope](https://github.com/hyperledger/aries-rfcs/tree/master/features/0334-jwe-envelope). +The ciphersuites defined in this RFC are a subset of the definitions in [Aries RFC 0334-jwe-envelope](https://github.com/hyperledger/aries-rfcs/tree/main/features/0334-jwe-envelope). ## Encryption Algorithms @@ -162,7 +162,7 @@ To advertise the combination of Envelope v2 with a DIDComm v1 message, the media ## Additional AIP impacts -Implementors supporting an AIP sub-target that contains this RFC (e.g., `DIDCOMMV2PREP`) MAY choose to only support Envelope v2 without support for the original envelope declared in [RFC 0019](https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope). In these cases, the `accept` property will not contain `didcomm/aip2;env=rfc19` media type. +Implementors supporting an AIP sub-target that contains this RFC (e.g., `DIDCOMMV2PREP`) MAY choose to only support Envelope v2 without support for the original envelope declared in [RFC 0019](https://github.com/hyperledger/aries-rfcs/tree/main/features/0019-encryption-envelope). In these cases, the `accept` property will not contain `didcomm/aip2;env=rfc19` media type. ## Drawbacks @@ -177,9 +177,9 @@ Aries agents currently use the envelope described in [RFC0019](/features/0019-en ## Prior art - The [JWE](https://tools.ietf.org/html/rfc7518) family of encryption methods. -- [Aries RFC 0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/master/features/0019-encryption-envelope) suggested envelope formats will be superseded by this RFC. -- [Aries RFC 0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/master/features/0025-didcomm-transports#reference) for the content type used in the proposed envelopes. -- [Aries RFC 0334-jwe-envelope](https://github.com/hyperledger/aries-rfcs/tree/master/features/0334-jwe-envelope). +- [Aries RFC 0019-encryption-envelope](https://github.com/hyperledger/aries-rfcs/tree/main/features/0019-encryption-envelope) suggested envelope formats will be superseded by this RFC. +- [Aries RFC 0025-didcomm-transports](https://github.com/hyperledger/aries-rfcs/tree/main/features/0025-didcomm-transports#reference) for the content type used in the proposed envelopes. +- [Aries RFC 0334-jwe-envelope](https://github.com/hyperledger/aries-rfcs/tree/main/features/0334-jwe-envelope). - [DIDComm Messaging](https://identity.foundation/didcomm-messaging/spec). - [minimal-cipher](https://github.com/digitalbazaar/minimal-cipher) implementation - [Public Key Authenticated Encryption for JOSE: ECDH-1PU](https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03) diff --git a/features/0641-linking-binary-objects-to-credentials/README.md b/features/0641-linking-binary-objects-to-credentials/README.md index 6ff1cc5e2..e1608e507 100644 --- a/features/0641-linking-binary-objects-to-credentials/README.md +++ b/features/0641-linking-binary-objects-to-credentials/README.md @@ -9,7 +9,7 @@ ## Summary -This RFC provides a solution for issuing and presenting credentials with external binary objects, after referred to as attachments. It is compatible with [0036: Issue Credential Protocol V1](https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential), [0453: Issue Credential Protocol V2](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2), [0037: Present Proof V1 protocol](https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof) and [0454: Present Proof V2 Protocol](https://github.com/hyperledger/aries-rfcs/tree/master/features/0454-present-proof-v2). These external attachments could consist of images, PDFs, zip files, movies, etc. Through the use of `DIDComm attachments`, [0017: Attachments](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments), the data can be embedded directly into the attachment or externally hosted. In order to maintain integrity over these attachments, hashlinks are used as the checksum. +This RFC provides a solution for issuing and presenting credentials with external binary objects, after referred to as attachments. It is compatible with [0036: Issue Credential Protocol V1](https://github.com/hyperledger/aries-rfcs/tree/main/features/0036-issue-credential), [0453: Issue Credential Protocol V2](https://github.com/hyperledger/aries-rfcs/tree/main/features/0453-issue-credential-v2), [0037: Present Proof V1 protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0037-present-proof) and [0454: Present Proof V2 Protocol](https://github.com/hyperledger/aries-rfcs/tree/main/features/0454-present-proof-v2). These external attachments could consist of images, PDFs, zip files, movies, etc. Through the use of `DIDComm attachments`, [0017: Attachments](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0017-attachments), the data can be embedded directly into the attachment or externally hosted. In order to maintain integrity over these attachments, hashlinks are used as the checksum. ## Motivation @@ -17,7 +17,7 @@ Many use cases, such as a rental agreement or medical data in a verifiable crede ## Tutorial -It is already possible to issue and verify base64-encoded attachments in credentials. When a credential is getting larger and larger, it becomes more and more impractical as it has to be signed, which is time consuming and resource intensive. A solution for this is to use the attachments decorator. This decorator creates a way to externalize the attachment from the credential attributes. By allowing this, the signing will be faster and more consistent. However, DIDComm messages SHOULD stay small, like with SMTP or Bluetooth, as specified in [0017: Attachments](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments). In the attachments decorator it is also possible to specify a list of URLs where the attachment might be located for download. This list of URLs is accompanied by a `sha256` tag that is a checksum over the file to maintain integrity. This `sha256` tag can only contain a sha256 hash and if another algorithm is preferred then the hashlink MUST be used as the checksum. +It is already possible to issue and verify base64-encoded attachments in credentials. When a credential is getting larger and larger, it becomes more and more impractical as it has to be signed, which is time consuming and resource intensive. A solution for this is to use the attachments decorator. This decorator creates a way to externalize the attachment from the credential attributes. By allowing this, the signing will be faster and more consistent. However, DIDComm messages SHOULD stay small, like with SMTP or Bluetooth, as specified in [0017: Attachments](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0017-attachments). In the attachments decorator it is also possible to specify a list of URLs where the attachment might be located for download. This list of URLs is accompanied by a `sha256` tag that is a checksum over the file to maintain integrity. This `sha256` tag can only contain a sha256 hash and if another algorithm is preferred then the hashlink MUST be used as the checksum. When issuing and verifying a credential, messages have to be sent between the holder, issuer and verifier. In order to circumvent additional complexity, such as looking at previously sent credentials for the attachment, the attachments decorator, when containing an attachment, MUST be sent at all of the following steps: @@ -66,7 +66,7 @@ Attachments can be inlined in the credential attribute as a base64-encoded strin When the attachments decorator is used to issue a credential with a binary object, a link has to be made between the credential value and the corresponding attachment. This link MUST be a hash, specifically a hashlink based on the checksum of the attachment. -As stated in [0008: message id and threading](https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0008-message-id-and-threading/README.md), the `@id` tag of the attachment MUST NOT contain a colon and MUST NOT be longer than 64 characters. because of this, the `@id` can not contain a hashlink and MUST contain the multihash with a maximum length of 64 characters. When a hash is longer than 64 character, use the first 64 characters. +As stated in [0008: message id and threading](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0008-message-id-and-threading/README.md), the `@id` tag of the attachment MUST NOT contain a colon and MUST NOT be longer than 64 characters. because of this, the `@id` can not contain a hashlink and MUST contain the multihash with a maximum length of 64 characters. When a hash is longer than 64 character, use the first 64 characters. ```json { @@ -203,8 +203,8 @@ The Identity Foundation is currently working on confidential storage, a way to a ## Prior art -- [0017: Attachments](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments) discusses the attachments in DIDcomm messaging and formulates the attachment decorator. -- [HIPE-0139: Image As Attribute Via Aries-0036 Issue-Credential Protocol](https://github.com/hyperledger/indy-hipe/blob/master/text/0139-image-as-cred-attr/README.md) has been written for the support of images in credentials. It points out that the attachment RFC and the issue credential RFC are separate and could drift apart. +- [0017: Attachments](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0017-attachments) discusses the attachments in DIDcomm messaging and formulates the attachment decorator. +- [HIPE-0139: Image As Attribute Via Aries-0036 Issue-Credential Protocol](https://github.com/hyperledger/indy-hipe/blob/main/text/0139-image-as-cred-attr/README.md) has been written for the support of images in credentials. It points out that the attachment RFC and the issue credential RFC are separate and could drift apart. - [Linking and Exchanging Attachments with Verifiable Credentials](https://sovrin.org/interoperability-series-linking-and-exchanging-attachments-with-verifiable-credentials/) describes the linking between the attachment the credential based on the `@id` tag. ## Unresolved questions diff --git a/features/0646-bbs-credentials/README.md b/features/0646-bbs-credentials/README.md index 80a8929b6..a70089a23 100644 --- a/features/0646-bbs-credentials/README.md +++ b/features/0646-bbs-credentials/README.md @@ -103,15 +103,15 @@ Below is a complete example of a Verifiable Credential with BBS+ linked data pro While the process of creating credentials with BBS+ signatures is defined in specifications outside of Aries, the process of exchanging credentials with BBS+ signatures is defined within Aries. -Credentials with BBS+ signatures can be exchanged by following [RFC 0453: Issue Credential Protocol 2.0](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2). The Issue Credential 2.0 provides a registry of attachment formats that can be used for credential exchange. Currently, agents are expected to use the format as described in RFC 0593 (see below). +Credentials with BBS+ signatures can be exchanged by following [RFC 0453: Issue Credential Protocol 2.0](https://github.com/hyperledger/aries-rfcs/tree/main/features/0453-issue-credential-v2). The Issue Credential 2.0 provides a registry of attachment formats that can be used for credential exchange. Currently, agents are expected to use the format as described in RFC 0593 (see below). -> NOTE: Once [Credential Manifest](https://identity.foundation/credential-manifest/) v1.0 is released, RFC 0593 is expected to be deprecated and replaced by an updated version of [RFC 0511: Credential-Manifest Attachment format](https://github.com/hyperledger/aries-rfcs/blob/master/features/0511-dif-cred-manifest-attach/README.md) +> NOTE: Once [Credential Manifest](https://identity.foundation/credential-manifest/) v1.0 is released, RFC 0593 is expected to be deprecated and replaced by an updated version of [RFC 0511: Credential-Manifest Attachment format](https://github.com/hyperledger/aries-rfcs/blob/main/features/0511-dif-cred-manifest-attach/README.md) ##### 0593: JSON-LD Credential Attachment format -[RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials](https://github.com/hyperledger/aries-rfcs/blob/master/features/0593-json-ld-cred-attach/README.md) defines a very simple, feature-poor attachment format for issuing JSON-LD credentials. +[RFC 0593: JSON-LD Credential Attachment format for requesting and issuing credentials](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md) defines a very simple, feature-poor attachment format for issuing JSON-LD credentials. -The only requirement for exchanging BBS+ credentials, in addition to the requirements as specified in [Creating BBS+ Credentials](#creating-bbs-credentials) and [RFC 0593](https://github.com/hyperledger/aries-rfcs/blob/master/features/0593-json-ld-cred-attach/README.md), is the `options.proofType` in the [`ld-proof-vc-detail`](https://github.com/hyperledger/aries-rfcs/blob/master/features/0593-json-ld-cred-attach/README.md#ld-proof-vc-detail-attachment-format) MUST be `BbsBlsSignature2020`. +The only requirement for exchanging BBS+ credentials, in addition to the requirements as specified in [Creating BBS+ Credentials](#creating-bbs-credentials) and [RFC 0593](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md), is the `options.proofType` in the [`ld-proof-vc-detail`](https://github.com/hyperledger/aries-rfcs/blob/main/features/0593-json-ld-cred-attach/README.md#ld-proof-vc-detail-attachment-format) MUST be `BbsBlsSignature2020`. ### Presenting Derived Credentials @@ -157,13 +157,13 @@ Same as with [Transforming Blank Node Identifiers](#transforming-blank-node-iden #### Exchanging Derived Credentials -The presentation of credentials with BBS+ signatures can be exchanged by following [RFC 0454: Present Proof Protocol 2.0](https://github.com/hyperledger/aries-rfcs/blob/master/features/0454-present-proof-v2). The Present Proof Protocol 2.0 provides a registry of attachment formats that can be used for presentation exchange. Although agents can use any attachment format they want, agents are expected to use the format as described in RFC 0510 (see below). +The presentation of credentials with BBS+ signatures can be exchanged by following [RFC 0454: Present Proof Protocol 2.0](https://github.com/hyperledger/aries-rfcs/blob/main/features/0454-present-proof-v2). The Present Proof Protocol 2.0 provides a registry of attachment formats that can be used for presentation exchange. Although agents can use any attachment format they want, agents are expected to use the format as described in RFC 0510 (see below). ##### 0510: Presentation-Exchange Attachment format -[RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs](https://github.com/hyperledger/aries-rfcs/blob/master/features/0510-dif-pres-exch-attach/README.md) defines an attachment format based on the [DIF Presentation Exchange](https://identity.foundation/presentation-exchange/) specification. +[RFC 0510: Presentation-Exchange Attachment format for requesting and presenting proofs](https://github.com/hyperledger/aries-rfcs/blob/main/features/0510-dif-pres-exch-attach/README.md) defines an attachment format based on the [DIF Presentation Exchange](https://identity.foundation/presentation-exchange/) specification. -The following part of this section describes the requirements of exchanging derived credentials using the Presentation Exchange Attachment format, in addition to the requirements as specified above and in [RFC 0510](https://github.com/hyperledger/aries-rfcs/blob/master/features/0510-dif-pres-exch-attach/README.md). +The following part of this section describes the requirements of exchanging derived credentials using the Presentation Exchange Attachment format, in addition to the requirements as specified above and in [RFC 0510](https://github.com/hyperledger/aries-rfcs/blob/main/features/0510-dif-pres-exch-attach/README.md). The Presentation Exchange MUST include the `ldp_vp` [Claim Format Designation](https://identity.foundation/presentation-exchange/#claim-format-designations). In turn the `proof_type` property of the `ldp_vp` claim format designation MUST include the `BbsBlsSignatureProof2020` proof type. @@ -259,12 +259,12 @@ It was then further refined by [Camenisch, Drijvers, and Lehmann in section 4.3 of this paper from 2016](https://eprint.iacr.org/2016/663.pdf). In 2019, Evernym and Sovrin proposed [BBS+ Signatures as the foundation for Indy Anoncreds 2.0](https://github.com/hyperledger/ursa-docs/tree/main/specs/anoncreds2), -which in conjunction with [Rich Schemas](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas) +which in conjunction with [Rich Schemas](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0250-rich-schemas) addressed a similar set of goals and capabilities as those addressed here, but were ultimately too heavy a solution. In 2020, Mattr provided [a draft specification for BBS+ LD-Proofs](https://w3c-ccg.github.io/ldp-bbs2020/) that comply with [the Linked Data proof specification](https://w3c-ccg.github.io/ld-proofs/) in the W3C Credentials Community Group. The authors acknowledged that their approach did not support two key Anoncreds features: proof predicates and link secrets. -[Aries RFC 593](https://github.com/hyperledger/aries-rfcs/tree/master/features/0593-json-ld-cred-attach) describes the JSON-LD credential format. +[Aries RFC 593](https://github.com/hyperledger/aries-rfcs/tree/main/features/0593-json-ld-cred-attach) describes the JSON-LD credential format. ## Unresolved questions