Problem
=======
See #263 

Solution
========
- Moved old Public Key Announcement to "Migrated Announcements".
- Added Avro type PublicKey.
- Updated User Data section to define key agreement and assertion method
key types.

---------

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>

Problem
=======
#267 discusses the advantages of DSNP profile documents being
discoverable based on a user's identifier, rather than being temporal
data that must be externally tracked and indexed to be useful.

Solution
========
This proposal adds a new User Data type, `profileResources`, which is
currently defined for the Activity Content profile document type, but is
extensible to other document types that may need to be user-centric in
the future.
A profile resource is simply a link type (as an integer) and a CID as a
string plus byte length.
We define link type 1 for AC profiles.

This change assumes we are versioning for 1.3, but does not include
versioning updates, which are in other open PRs at this time.

Change summary:
---------------
- [ ] ~~Updated Spec Versions~~
- [x] Added definition for ProfileResource Avro type
- [x] Added entry in User Data page for `profileResource`
- [x] Updated navigation; added ProfileResource, moved Profile
announcement to "Migrated" section

---------

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>

Output of npm audit fix, fixes
https://github.com/LibertyDSNP/spec/security/dependabot/43 and another
item

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>

Problem
=======
DSNP should provide affordances for finding content that do not rely on
a single DNS-based point of failure for content hosting.
More in the original discussion: #273 

Solution
========
Enhance the specification to treat URLs in Announcements as suggestions
rather than canonical locations for content.
Provide a simple and well-specified set of hashes and encodings that can
be used consistently throughout the protocol.
Use IPFS CIDv1 specifically for locating profiles.

Change summary:
---------------
* Broaden ProfileResource definition so that different types of profile
resources can use different, possibly distributed, file systems via a
generic `contentAddress` field
* Simplify multihashes to use base32 encoding only and sha2-256 or
blake3 as the hashing algorithm
* Update various example hashes in line with this
* Update to pre-1.3.0 versioning and sync prerelease changelogs for
other recent additions to the spec
* Change spec language to expand on how to treat content hash + URL
pairs.
* Announcements use the same base32 encoded multihash for the
`contentHash` and `targetContentHash` fields.

---------

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>

Problem
=======
Link to GitHub Issue(s): #257 

Solution
========
Adds affordances for Attribute Sets via the Verifiable Credentials
format.
Adds three new announcement types for Attribute Sets.
Specifies DSNP compliance criteria for use of VCs, and includes DSNP
extensions for chains of trust and display of credentials.
Extends DSNP Activity Content usage to enable Attestations as
attachments.

---------

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>

Remove Rococo, update DSNP 1.3 mappings, errata for
public-key-key-agreement multicodec confusion

Still some TBDs on schema Ids, tentatively trying to get those in before
we merge this.

---------

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>

Update core spec, Activity Content subspec, and (new) Verifiable
Credentials subspec to v1.3.0.

Co-authored-by: Wes Biggs <wes.biggs@amplica.io>