Merge branch 'main' into vdrproxy

concepts/0530-goal-human-readable-verified-identifer/README.md

@@ -0,0 +1,57 @@
+# Aries RFC 0530: Goal - Human Readable Verifiable Identifier
+
+- Authors: [Sam Curren]([email protected])
+- Status: [PROPOSED](/README.md#proposed)
+- Since: 2020-08-26
+- Status Note: Early Proposal
+- Start Date: 2020-08-26
+- Tags: goalcode
+
+## Summary
+
+DIDs are not human friendly. DIDComm provides a secure connection between two DIDs. This goal code seeks to provide a verifiable, human readable identifier from one party to another.
+
+## Motivation
+
+Presenting a Human Readable Verifiable Identifier over a DIDComm connection aids the user in positive connection identification. It also plays a role in Man-in-the-Middle (MitM) attack prevention.
+
+## Reference
+
+### Goal Code
+
+`aries.receive.verifiable.identifier`
+
+### Explanation
+
+The party presenting this goal code has a goal of receiving a human readable verifiable identifier from the party it presents it to.
+
+### Key Concepts
+
+Human Readable implies that the identifier is meaningful to a human. This might be an identifier already used to communicate, such as an email address, phone number, website domain name, or social media account name.
+
+A Verifiable identifier requires that some level of assurance is provided that control has been proven over the identifier. 
+
+Governance Frameworks that serve this goal code must provide details about which identifiers are acceptable, and how they are to be verified.  
+
+## Governance Frameworks 
+
+The following Governance Frameworks are related to this goal code.
+
+- Domain Control 
+- Email Ownership
+
+## Unresolved questions
+
+- 
+
+## Implementations
+
+> NOTE: This section should remain in the RFC as is on first release. Remove this note and leave the rest of the text as is. Template text in all other sections should be removed before submitting your Pull Request.
+
+The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.
+
+*Implementation Notes* [may need to include a link to test results](README.md#accepted).
+
+Name / Link | Implementation Notes
+--- | ---
+ |

concepts/0535-email-access-governance-framework/README.md

@@ -0,0 +1,90 @@
+# 0535: Email Access Governance Framework
+- Authors: [Sam Curren]([email protected])
+- Status: [PROPOSED](/README.md#proposed)
+- Since: 2020-09-16
+- Status Note: Proposed, but in need of specifics to put into action.
+- Start Date: 2020-07-14
+- Tags: feature, protocol
+
+## Summary
+
+
+> Note: This RFC was created in advance of the [Credential Trust Establishment](https://identity.foundation/credential-trust-establishment/) spec work at the DIF. The concepts are good, but the governance mechanism should be updated to use this newer spec before action is taken.
+
+This Governance Framework is community managed.
+
+When making connections from one person to another over DIDComm, it is useful to be able to gain proof of something to verify that the connection is with the right person and has not been subject to a MITM attack. We expect this Governance Framework to be one of many used for the purpose of helping to verify identity attributes in the creation of trusted channels.
+
+This is an early attempt at the creation and use of of a practical governance framework. As Governance Framework technology improves, we expect this particular framework to be replaced.
+
+## Purpose
+
+To facilitate the verification of email access between two parties over DIDComm and related technologies.
+
+## Details
+
+### Goal Codes
+
+This Governance framework satisfies the following goal code(s):
+
+`aries.receive.verifiable.identifier`
+
+### Protocols
+
+`https://didcomm.org/present-proof/2.0/`
+
+### Roles
+
+**issuer**: Responsible for issuing credentials according to the requirements of this governance framework.
+
+### Schemas
+
+_TODO: schemas listed here_
+
+### Issuers
+
+BCGov (DID?)
+
+### Issue Requirements
+
+Issuers must validate email ownership by sending an email to the email address in question. The email MUST contain a link for the user to click, or a code to be entered in a verification step. After verifying that the clicked link or entered code matches, the credential may be issued.
+
+Issued credentials should indicate an expiration date no longer than 6 months from the date of verification.
+
+### Revocation
+
+This framework does not currently use revocation, relying upon the expiration date to prevent widespread issues.
+
+### Allowable Verification Purposes
+
+Email addresses revealed in this manner may be used for the following purposes:
+
+- Displaying to recipient.
+- Checking against address book.
+
+Use outside these purposes, including the following examples, violates the allowed uses as specified by this governance framework.
+
+- Sending email to the address without explicit additional approval of the user.
+- Sharing email address with any other party.
+
+### Machine Readable Document
+
+Located [here](data.json).
+
+## Notes
+
+- The machine readable document is as simple as possible by design. As related technology improves, the document will be updated to reflect these changes.
+- Code for the indy email verification service: https://github.com/bcgov/indy-email-verification that could be used as a basis for an issuer.
+
+## Unresolved questions
+
+- Which networks?
+- Need Schemas and Issuers
+## Uses
+
+The following libraries or applications use this Governance Framework.
+
+Name / Link | Implementation Notes
+--- | ---
+ | 
+

concepts/0535-email-access-governance-framework/data.json

@@ -0,0 +1,12 @@
+{
+    "@context": ["https://github.com/hyperledger/aries-rfcs/blob/master/0430-machine-readable-governance-frameworks/context.jsonld"],
+    "name": "Email Access"
+    "version": "0.1",
+    "description": "Proof of email access, useful for proving a common identifier and/or validating an email address without performing a live loop-back test."
+    "last_updated": "2020-09-16",
+    "docs_uri": "http://github.com/hyperledger/aries-rfcs/blob/master/",
+    "data_uri": "<uri to machine readable portion of this example>",
+    "schemas": ["schemaidhere"],
+    "roles": ["issuer"], 
+    "rules": [ {"when": {"id": "did:example:abc123"}, "thus": "issuer"} ]
+}   

concepts/0781-trust-input-protocol/README.md

@@ -0,0 +1,185 @@
+
+# RFC 0781 Trust Input Protocol
+- Authors: Mathieu Glaude, Subhasis Ojha
+- Status: PROPOSED
+- Since: 2023-11-23
+- Status Note: New RFC being proposed
+- Supersedes: None
+- Start Date: 2023-11-23
+
+ ## Summary
+
+ The Trust Input Protocol is a conceptual framework designed to assist with the making of trust decisions within digital interactions. It emphasizes the importance of both technical (cryptographic) trust and human trust. The protocol introduces the concept of "Trust Inputs," which are sources of information that assist entities in making trust decisions. For the purpose of this RFC, trust inputs may only come from Trust Registries that support DIDComm-based messaging, based on [RFC 0160: Connection Protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0160-connection-protocol/README.md). The first use case that this framework looks to support is allowing verifiers of a digital credential proof presentation to query the authoritativeness of digital credential issuers against trust registries.
+
+ ## Motivation
+
+The primary motivation for creating a Trust Input Protocol is to address the challenges of establishing trust in digital interactions. As digital transactions become more prevalent, there's a growing need to ensure that parties can trust each other, especially in contexts where real or perceived risks are involved. Traditional cryptographic methods provide technical trust, ensuring that data hasn't been altered or falsified. However, they don't address the human aspect of trust, such as verifying the authenticity of a claim or ensuring that a claim has been issued by a recognized authority. The Trust Input Protocol aims to bridge this gap by providing a framework where parties can seek trust inputs from various sources to make informed trust decisions. Although we focus on trust registries in the short-term, we imagine this protocol being capable of allowing trust decision making entities to seek inputs from sources outside of trust registries. For this reason, we will use the broader term `trust-input`.
+
+![Making a trust decision](https://github.com/Northern-Block/trustinputprotocol/blob/main/trust-inputs-flow.png)
+
+This above diagram was taken from a June 29, 2023 presentation given to the Trust over IP Foundation ([Slides](https://docs.google.com/presentation/d/1UMacqKZOEXiisNMz38_47FmJBUj69XePcTg9WbUCJtw/edit?usp=sharing), [Recording](https://zoom.us/rec/share/Hx-3oOZBL_vIPgf-2I6zP7QuBdQNKki4yULa2U71-VMvIrXUrS21HBAobYKBoUV5.gDEK5BKn5yJUq7nN)).
+
+Trust registries are authoritative sources of information that we can use as inputs to make trust decisions. In the digital credentialing world, we can imagine sometimes needing to check an authoritative source to know if a credential was issued by an authority. And the reason for a protocol? We want to make sure we avoid building proprietary solutions and rather work with the community to develop standards and protocols that can be used by any implementer.
+
+Inspiration for this protocol was taken from [RFC 0113: Question Answer Protocol](https://github.com/hyperledger/aries-rfcs/blob/main/features/0113-question-answer/README.md). We have gone beyond this protocol by adding structure to it, since we need a standard method for requesting for authorization related to credential issuance contexts.
+
+ ## Tutorial
+
+ This RFC introduces a protocol for interacting with trust registries. The identifier for the message family used by this protocol is `trust-input`, and the fully qualified URI for its definition is: 
+
+ *https://didcomm.org/trust-input/1.0*
+
+  ## Roles
+
+  There are two roles in the `trust-input` protocol: `requestor` and `trust-registry`. The `requestor` asks the `trust-registry` if credential metadata of a verifiable credential shared by a holder was issued by an authorized issuer, and the `trust-registry` responds with an answer. Any type of entity can be a requestor and inquire about the authority of an issuing entity. All the requests sent by the requestor are sent in a single message type, and the same is true for the response from the `trust-registry`.
+
+  ## States
+
+  This is a classic two-step request~response interaction, so it uses the predefined state machines for any `requestor` and `trust-registry`:
+
+<img src= "https://github.com/Northern-Block/trustinputprotocol/blob/main/trust-input-states.png" width="408.16" height="300">
+
+  ## Messages
+
+ ### query Message Type
+
+A trust-input-protocol/query message looks like this:
+
+    {
+    "@type": "https://didcomm.org/trust-input/1.0/query",
+      	"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
+      	"query": {
+        		"trust-task":"issuance",
+        		"include-governance":"yes",
+        		"credentialmetadata":[
+          			{
+            		"credential-id": "http://university.example/credentials/1872",
+    			"credential-format": "1",
+            		"issuer-did": "did:example:123456abcdef"
+          			}
+        		]
+        	},
+      	"comment": "Please tell me if this issuer is authoritative to issue this credential type..."
+    }
+
+The query message says, “ Please tell me if the issuer: ‘did:example:123456abcdef’ is authorized to issue the credential: ‘http://university.example/credentials/1872’. And please give me information about the governance framework that governs the trust registry operation.” Please refer to the Localisation section below for further details.
+
+The `requestor` can send an array of issuers and credentials in their request to the trust registry. If they’re seeking multiple trust inputs from a single trust registry, they can get them in a single request.
+
+The values for `credential-format` are:
+
+    1 = AnonCreds
+    2 = JSON-LD
+    3 = JWT
+
+Additional formats can be supported and added to this above list.
+
+The credential field within the requestor’s `query` may include a * wildcard. An example use of this could be “I’m interested in knowing all the credentials that this specific issuer is authorized to offer”. This may be useful for discovery purposes.
+
+### response Message Type
+
+A trust-input/response message looks like this:
+
+    { 
+    "@type": "https://didcomm.org/trust-input/1.0/response",
+    "~thread": {
+          	"thid": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU" 
+      	},
+      	"governance":"http://university.example/governanceframework",
+      	"response":[	
+    {
+          		"credential-id": "http://university.example/credentials/1872",
+          		"status": "2",
+            	"status_date":"yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fff'Z'"
+        		}
+    	]
+    }
+
+The `response` field is a JSON array of response support descriptor objects that matches the query. Each descriptor has a `credential-id` that contains a credential (fully qualified verifiable credential id), plus the current authoritative `status` of the credential issuer to issue said credential.
+
+The response returns the current status of the credential issuer(s) against their authority to issue credentials at the time of `query`.
+
+The values for `status` are:
+
+    1 = Not found
+    2 = Valid
+    3 = Expired (not renewed after the previous valid registration period) [when was it expired]
+    4 = Terminated (voluntary termination by the registered party) [when was it terminated]
+    5 = Revoked [when was it revoked]
+
+For status values 3, 4, 5; the trust registry will return a date value of when that status became that value.
+
+A `query` which contains a *wildcard would return all the credentials offered by the issuer’s DID.
+The date format returned in the response is a web UTC format. The date represents  the status changes of status values and the `requestor` can use that info to make their trust decision.
+
+## Trust Registry Considerations
+
+### Connection Establishment
+
+The connection between the `requestor` and the `trust-registry` is established via an out-of-band message sent to the `requestor`. Other connection methods such as [RFC 0160](https://github.com/hyperledger/aries-rfcs/blob/main/features/0160-connection-protocol/README.md) can also be used.
+
+### Identifier
+
+`trust-registry` must have a resolvable Verifiable Identifier (VID).
+
+### Governance
+
+The trust registries that an entity using this protocol will interact with should ensure their trust registries are aligned with the [Trust over IP’s Trust Registry Governance Framework](https://github.com/trustoverip/tswg-trust-registry-tf/blob/main/v2/requirements.md#governing-authorities).
+
+A governance document must be published to be able to respond to a request that asks for governance.
+
+## Localization
+
+Because the `requestor` is being returned a status number to represent the status, the implementers can use this to localise it in the language of their choice and make it friendly to their application or user experience.
+
+The `query` message contains a `comment` field that is localizable. This field is optional and may not be often used, but when it is, it is to provide a human-friendly justification for the query. An agent that consults its master before answering a query could present the content of this field as an explanation of the request.
+
+All message types in this family thus have the following implicit decorator:
+
+    {
+
+    "~l10n": {
+	    "locales": { "en": ["comment"] },
+	    "catalogs": ["https://github.com/hyperledger/aries-rfcs/features/trust-input/requestor/catalog.json"]
+
+		    }
+    }
+
+
+For more information, see the [localization RFC](https://github.com/hyperledger/aries-rfcs/blob/main/features/0043-l10n/README.md).
+
+
+## Open Topics
+
+-   How to implement using [RFC 0434: Out-of-Band Protocol 1.1](https://github.com/hyperledger/aries-rfcs/blob/main/features/0434-outofband/README.md)? We plan to leave this out of scope until a further version.
+- Governance on how the credential id is entered into a trust registry will be required. And this is dependent on the credential format. So there will likely be a required field in the trust registry for credential format, which would then dictate how the credential id is entered. The format for the credential metadata in the trust registry must align with the format received by the `requestor`.
+
+
+## Acknowledgements
+
+Although many people helped with the thinking behind this protocol, the authors would like to specifically thank these following people for their support and contributions:
+
+-   British Columbia Government - Kyle Robinson and Nancy Norris
+
+-   CIRA - Jacques Latour and Jesse Carter
+
+-   Continuum Loop - Darrell O’Donnell
+
+-   IDLab - Cosanna Preston-Idedia and Hadrien Seymour-Provencher
+
+-   Trust over IP’s Trust Registry Task Force
+
+
+## Implementations
+
+The following lists the implementations (if any) of this RFC. Please do a pull request to add your implementation. If the implementation is open source, include a link to the repo or to the implementation within the repo. Please be consistent in the "Name" field so that a mechanical processing of the RFCs can generate a list of all RFCs supported by an Aries implementation.
+
+
+| Name/Link | Implementation Notes |
+|--|--|
+| [nborbit.io](http://nborbit.io) | Commercial trust task orchestration application built by [Northern Block](https://northernblock.io/) using Aries Cloud Agent Python (ACA-Py). |
+
+
+
+
+

concepts/0781-trust-input-protocol/Test

@@ -0,0 +1 @@
+.