Merge branch 'main' into email_access_gov_fwk

.github/dependabot.yml

@@ -0,0 +1,39 @@
+ # For details on how this file works refer to:
+ #   - https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
+version: 2
+updates:
+  # Maintain dependencies for GitHub Actions
+  #  - Check for updates once a week
+  #  - Group all updates into a single PR
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    groups:
+      all-actions:
+        patterns: [ "*" ]
+
+  # Maintain dependencies for Python Packages
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "04:00"
+      timezone: "Canada/Pacific"
+    ignore:
+      - dependency-name: "*"
+        update-types: ["version-update:semver-major"]
+
+  # Maintain dependencies for Python Packages
+  - package-ecosystem: "pip"
+    directory: "/.circleci"
+    schedule:
+      interval: "weekly"
+      day: "monday"
+      time: "04:00"
+      timezone: "Canada/Pacific"
+    ignore:
+      - dependency-name: "*"
+        update-types: ["version-update:semver-major"]
+

.github/workflows/publish-site.yml

@@ -0,0 +1,39 @@
+name: publish-docs 
+
+on:
+  push:
+    # Publish `main` as latest, and when pushes are done to branches with "v-doc" prefix
+    branches:
+      - main
+
+permissions:
+  contents: write
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0 # fetch all commits/branches
+      - uses: actions/setup-python@v5
+        with:
+          python-version: 3.x
+      - uses: actions/cache@v4
+        with:
+          key: ${{ github.ref }}
+          path: .cache
+      - name: Install Python dependencies
+        run: pip install -r ./mkdocs-requirements.txt
+      - name: Configure git user
+        run: |
+          git config --local user.email "github-actions[bot]@users.noreply.github.com"
+          git config --local user.name "github-actions[bot]"
+
+      - name: Deploy docs
+        run: |
+          python --version
+          # Generate the content into the docs folder
+          code/genSite.sh
+          mike deploy --push --update-aliases main latest
+          mike set-default latest

.gitignore

@@ -5,3 +5,4 @@ __pycache__
 *.pyc
 *.tmp
 .pytest_cache
+docs

0000-template-protocol.md

@@ -1,6 +1,6 @@
 # Aries RFC 0000: Your Protocol 0.9
 
-- Authors: [your name](you@github-email) -- email is optional
+- Authors: [your name](mailto:you@github-email) -- email is optional
 - Status: [PROPOSED](/README.md#proposed)
 - Since: 2019-12-26 (date you submit your PR)
 - Status Note: (explanation of current status)  
@@ -31,7 +31,7 @@ Specify the official name of the protocol and its version, e.g., "My Protocol 0.
 
 Protocol names are often either lower_snake_case or kebob-case. The non-version components of the protocol named are matched exactly.
 
-URI: https://didcomm.org/lets_do_lunch/<version>/<messageType>
+URI: `https://didcomm.org/lets_do_lunch/<version>/<messageType>`
 
 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.
 
@@ -159,7 +159,7 @@ Adoption should be declared in an "Adopted" subsection of "Messages".
 When adoption is specified, it should include a __minimum
 adopted version__ of the adopted message type: "This protocol adopts
 `ack` with version >= 1.4". All versions of the adopted message that share
-the same major number should be compatible, given the [semver rules](concepts/0003-protocols/semver.md)
+the same major number should be compatible, given the [semver rules](https://github.com/hyperledger/aries-rfcs/blob/main/concepts/0003-protocols/README.md#semver-rules-for-protocols)
 that apply to protocols.
 
 ### Constraints

0000-template.md

@@ -1,5 +1,5 @@
 # Title (Ex. 0000: RFC Topic)
-- Authors: [your name](you@github-email) -- email is optional
+- Authors: [your name](mailto:you@github-email) -- email is optional
 - Status: [PROPOSED](/README.md#proposed)
 - Since: 2019-12-26 (date you submit your PR)
 - Status Note: (explanation of current status)  

MAINTAINERS.md

@@ -0,0 +1,73 @@
+# Maintainers
+
+## Active Maintainers
+
+<!-- Please keep this sorted alphabetically by github -->
+
+| Name             | Github           | LFID             |
+| ---------------- | ---------------- | ---------------- |
+|	Daniel Hardman | dhh1128 | |
+|	George Aristy | llorllale | |
+|	Nathan George | nage | |
+|	Stephen Curran | swcurran | |
+|	Drummond Reed | talltree | |
+|	Sam Curren | TelegramSam | |
+
+## Emeritus Maintainers
+
+| Name         | Github  | LFID    |
+|--------------|---------|---------|
+|   |  |  |
+
+## Becoming a Maintainer
+
+The Aries community welcomes contributions. Contributors may progress to become a
+maintainer. To become a maintainer the following steps occur, roughly in order.
+
+- 5 significant changes have been authored by the proposed maintainer and
+  accepted.
+- The proposed maintainer has the sponsorship of at least one other maintainer.
+  - This sponsoring maintainer will create a PR modifying the list of
+    maintainers.
+  - The proposed maintainer accepts the nomination and expresses a willingness
+    to be a long-term (more than 6 month) committer.
+  - This would be a comment in the above PR.
+  - This PR will be communicated in all appropriate communication channels. It
+    should be mentioned in any maintainer/community call. It should also be
+    posted to the appropriate mailing list or chat channels if they exist.
+- Approval by at least 3 current maintainers within two weeks of the proposal or
+  an absolute majority of current maintainers.
+  - These votes will be recorded in the PR modifying the list of maintainers.
+- No veto by another maintainer within two weeks of proposal are recorded.
+  - All vetoes must be accompanied by a public explanation as a comment in the
+    PR for adding this maintainer
+  - The explanation of the veto must be reasonable.
+  - A veto can be retracted, in that case the approval/veto timeframe is reset.
+  - It is bad form to veto, retract, and veto again.
+- The proposed maintainer becomes a maintainer
+  - Either two weeks have passed since the third approval,
+  - Or an absolute majority of maintainers approve.
+  - In either case, no maintainer presents a veto.
+
+## Removing Maintainers
+
+Being a maintainer is not a status symbol or a title to be maintained
+indefinitely. It will occasionally be necessary and appropriate to move a
+maintainer to emeritus status. This can occur in the following situations:
+
+- Resignation of a maintainer.
+- Violation of the Code of Conduct warranting removal.
+- Inactivity.
+  - A general measure of inactivity will be no commits or code review comments
+    for one reporting quarter, although this will not be strictly enforced if
+    the maintainer expresses a reasonable intent to continue contributing.
+  - Reasonable exceptions to inactivity will be granted for known long term
+    leave such as parental leave and medical leave.
+- Other unspecified circumstances.
+
+Like adding a maintainer the record and governance process for moving a
+maintainer to emeritus status is recorded in the github PR making that change.
+
+Returning to active status from emeritus status uses the same steps as adding a
+new maintainer. Note that the emeritus maintainer already has the 5 required
+significant changes as there is no contribution time horizon for those.

README.md

@@ -8,8 +8,8 @@ If you are here to learn about Aries, we recommend you use the [the RFC Index](i
 
 There are 2 types of Aries RFCs:
 
-* RFCs that describe individual features (in the [features](./features) folder)
-* RFCs that explain concepts underpinning many features (in the [concepts](./concepts) folder)
+* RFCs that describe individual features (in the `./features` folder)
+* RFCs that explain concepts underpinning many features (in the `./concepts` folder)
 
 RFCs are for developers *building on* Aries. They don't provide guidance on how Aries components
 implement features internally; individual Aries repos have design docs for that. Each
@@ -20,7 +20,18 @@ Aries RFC includes an "implementations" section and all RFCs with a status great
 
 RFCs go through a standard lifecycle.
 
-![lifecycle](lifecycle.png)
+<!-- To edit this lifecycle drawing:
+ - Copy the URL below
+ - Navigate to https://www.plantuml.com/plantuml/uml/
+ - Paste the URL into the text area in the middle of the screen beside the "Decode URL" button.
+ - Click the "Decode URL" button and the editable Plantuml definition of the drawing will be in the top of the box.
+ - Edit the lifecycle drawing as desired.
+ - When complete, copy the resulting URL from the box. Note that the copied URL is missing the leading "https:".
+ - Replace the URL below, ensuring to add the `https:` at the beginning.
+ - Done!
+ -->
+
+![lifecycle](https://www.plantuml.com/plantuml/png/TP1DZeCm38NtEKK6rbnXHAKUe6gNg8iKN43AJ-GOUlsIoa60mYQs_Db-UQu3AQJ9QF570nYGy_X2PKayI178uWuq8dI5L45oBilbINm9MZFdVCjlwBmBiQR7Vg0U0IoZAnXd0w6YBBwqBVWJv3sw-O1MfQefVvLdzR_J43l1gdCVk-bCSeAJJ0Uh7lPeU5CJ7SSUlX0lESUyAeytLZ3wMpdVLt1Cq-iFqvoemNQJqLy0)
 
 #### PROPOSED
 To __propose__ an RFC, [use these instructions to raise a PR](
@@ -33,13 +44,17 @@ exploring.
 __Demonstrated__ RFCs have one or more implementations available, listed in the "Implementations" section of the RFC document. As with the PROPOSED status, demonstrated RFCs haven't been endorsed by the community, but the ideas put forth have been more thoroughly explored through the implementation(s). The demonstrated status is an optional step in the lifecycle. For protocol-related RFCs, work on protocol tests SHOULD begin in the [test suite repo](https://github.com/hyperledger/aries-protocol-test-suite) by the time this status is assigned.
 
 #### ACCEPTED
-To get an RFC __accepted__, [build consensus](contributing.md#how-to-get-an-RFC-accepted) for your RFC on [chat](https://chat.hyperledger.org/channel/aries) and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the [test suite repo](https://github.com/hyperledger/aries-protocol-test-suite), it MUST list the test suite in the protocol RFC's [Implementations section](../0000-template.md#implementations), at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.
+To get an RFC __accepted__, [build consensus](contributing.md#how-to-get-an-RFC-accepted) for your RFC on [chat](https://chat.hyperledger.org/channel/aries) and in community meetings. If your RFC is a feature that's protocol- or decorator-related, it MUST have reasonable tests in the [test suite repo](https://github.com/hyperledger/aries-agent-test-harness), it MUST list the test suite in the protocol RFC's [Implementations section](/0000-template.md#implementations), at least one other implementation must have passed the relevant portions of the test suite, and all implementations listed in this section of the RFC MUST hyperlink to their test results. An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation.
 
 #### ADOPTED
 To get an RFC __adopted__, [socialize and implement](contributing.md#how-to-get-an-rfc-adopted). An RFC gets this status once it has significant momentum--when implementations accumulate, or when the mental model it advocates has begun to permeate our discourse. In other words, adoption is acknowledgment of a _de facto_ standard.
 
 To __refine__ an RFC, propose changes to it through additional PRs. Typically these changes are driven by experience that accumulates during or after adoption. Minor refinements that just improve clarity can happen inline with lightweight review. Status is still ADOPTED.
 
+#### STALLED
+An RFC is __stalled__ when a [proposed](#proposed) RFC makes
+no progress towards implementation such that it is extremely unlikely it will ever move forward. The __stalled__ state differs from [retired](#retired) in that it is an RFC that has never been implemented or superseded. Like the [retired](#retired) state, it is (likely) an end state and the RFC will not proceed further. Such an RFC remains in the repository on the off chance it will ring a chord with others, be returned to the [proposed](#proposed) state, and continue to evolve.
+
 #### RETIRED
 An RFC is __retired__ when it is withdrawn from community consideration by its authors, when implementation seems permanently stalled, or when significant refinements require a superseding document. If a retired RFC has been superseded, its `Superseded By` field should contain a link to the newer spec, and the newer spec's `Supersedes` field should contain a link to the older spec. Permalinks are not broken.
 

code/aipUpdates.py

@@ -11,12 +11,13 @@
     description='List the RFCs set in an Aries Interop Profile (AIP) that have subsequently evolved. ' +
     'By default, the AIPs in the local version of the file are processed. A specific version can be ' +
     'specified, and then only that AIP version is processed. The AIP version can be a previous (not current) ' +
-    'AIP.  Optionally, the diffs between RFCs set in processed AIP and the "master" branch can be included.')
+    'AIP.  Optionally, the diffs between RFCs set in processed AIP and the "main" branch can be included.')
 
 # add arguments to the parser
 parser.add_argument('--version', '-v', help='The AIP version to display. Defaults to the current version(s) in the local file')
 parser.add_argument('--diffs', '-d', dest='diffs', action='store_true',
                     help='Display the diffs of any updated RFCs found')
+parser.add_argument('--list', '-l', help='List the RFCs and commits in the AIP with a prefixed by the name of a (for example) shell script')
 
 # parse the arguments
 args = parser.parse_args()
@@ -64,10 +65,10 @@ def readAIP( aip_path, version ):
     if aip_version:
         # Check if we want all the AIPs in the file or this one
         if ( not(args.version) or aip_version.group(1) == args.version ):
-            print("Aries Interop Profile: %s" % (aip_version.group(1)))
+            print("# Aries Interop Profile: %s" % (aip_version.group(1)))
             ListVersionRFCs = True
         else:
-            # Not this one...don't list the changed verion
+            # Not this one...don't list the changed version
             ListVersionRFCs = False
 
     rfc = re.search(_aip_commit_and_file, line)
@@ -76,14 +77,16 @@ def readAIP( aip_path, version ):
         # From the RFC line, get the commit ID and protocol file
         commit = rfc.group(3)
         protocol = rfc.group(5)
-        changed = re.search(protocol, subprocess.run(['git', 'diff', '--name-only', commit, 'master'], stdout=subprocess.PIPE).stdout.decode('utf-8'))
+        changed = re.search(protocol, subprocess.run(['git', 'diff', '--name-only', commit, 'main'], stdout=subprocess.PIPE).stdout.decode('utf-8'))
         # Has this RFC changed since it was set in the RFC?
-        if changed:
+        if args.list:
+            print('%s %s %s' % (args.list, protocol, commit))
+        elif changed:
             # Yes - list it.
             print('>>>>>>>> Changed protocol: %s, latest commit to protocol: %s' % (protocol, 
                 subprocess.run(['git', 'log', '-n', '1', '--pretty=format:%H', '--', protocol], stdout=subprocess.PIPE).stdout.decode('utf-8')))
             if args.diffs:
                 # If we're showing diffs, then show the diffs
                 print('')
-                print(subprocess.run(['git', 'diff', commit, 'master', protocol], stdout=subprocess.PIPE).stdout.decode('utf-8'))
+                print(subprocess.run(['git', 'diff', commit, 'main', protocol], stdout=subprocess.PIPE).stdout.decode('utf-8'))
 exit()

code/cpAIPs.sh

@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Usage: Given an RFC name and a commit, retrieve all the files of the RFC into the AIP RFC at the right commit.
+# Example: code/cpAIP.sh concepts/0003-protocols c3b0e2120ad24810598375663b6922b980f85d00
+# Designed to fetch files in subdirectories, although it is not clear how to add them to the documentatioon
+
+PROTOCOL=$1
+COMMIT=$2
+AIP2=aip2
+
+# echo Getting AIP docs for RFC $PROTOCOL, Commit $COMMIT
+cd docs
+for i in $(find $PROTOCOL -type f); do
+    AIPFile=$(echo $i | sed -r "s#(features|concepts)/#${AIP2}/#")
+    # echo $i $AIPFile
+    mkdir -p $(dirname $AIPFile)
+    curl -s https://raw.githubusercontent.com/hyperledger/aries-rfcs/${COMMIT}/$i -o $AIPFile
+done
+cd ..