Re: Is ActivityStreams Collection under-specified?

>
> *What standard(s) should I implement in order to most usefully publish a
> public-domain, signed, collection of items that sometimes refer to each
> other?*


probably Linked Data Platform or Solid
or HTML with some syntax for expressing signed claims. ActivityStreams
never had signed claims in scope, so I wouldn't recommend trying to make
that work in AS2 alone.

You may also want to participate in the standardization of the RDF Dataset
Canonicalization and Hashing Group.
https://github.com/w3c/rch-wg-charter/issues/38#issue-860615056
The output of that group will likely be standard and compatible with
ActivityStreams and ODRLd when mashed up.

Until then, you can also sign at the JSON layer using JSON Canonicalization
Scheme.

You can also have collection items refer to each other using URIs like
`urn:uuid:{uuid}`.

> This would argue for providing a simple general mechanism for making
references (i.e. Annotations)
JSON-LD is already a simple general mechanism for making references.
Everything is a reference. We don't need an 'Annotation' type for it. (even
if we did, as2 defines `Link` which is a reified link)


On Tue, Mar 14, 2023 at 2:07 PM Bob Wyman <bob@wyman.us> wrote:

> a wrote
>
>> i'm not sure why you would apply CRUD to Collections. we have Add and
>> Remove.:
>
> My point is that the very generic "Add" and "Remove" Activities are
> defined in the ActivityStreams Vocabulary
> <https://www.w3.org/TR/activitystreams-vocabulary/#activity-types>, mixed
> in with a bunch of "social" Activity types that are irrelevant to someone
> who is implementing a stand-alone Collection or a Collection in some
> non-social application. Also, there is essentially no discussion of what
> these activities mean when applied specifically to a Collection, what
> Collection-specific error handling might be needed, how access rights are
> to be handled, what Collection-specific conformance test might be defined,
> etc. The implementer of a Collection needs to ignore most of what is in the
> Activity* specifications. Such messiness is not useful.
>
> ActivityStreams and ActivityPub do not mandate any specific authentication
>> or verification or proof mechanism. *if they had, they would very
>> quickly be outdated.*
>
> No. I don't think so. We could today adopt a profile of RFC7515
> <https://www.rfc-editor.org/rfc/rfc7515>, JSON Web Signature (JWS), and
> be confident that it would remain useful as long as whatever cryptographic
> algorithm had been specified as preferred was still considered useful.
> Then, when that algorithm becomes deprecated, as all such algorithms one
> day will become, we could agree to commonly prefer some new algorithm in an
> updated profile, while preserving all of the algorithm-independent code
> related to signatures and all the code that relies on signatures. Yes,
> there is an issue concerning the persistence of any signing algorithm's
> utility, however, we can be certain that no algorithm currently known will
> remain useful forever. Waiting for the development of such an algorithm is
> probably a fool's errand and ensures that we'll never be able to enjoy the
> benefits provided by signatures.
>
> In any case, signatures are only useful if their readers know what they
> are and trust the algorithm used. So, there really isn't much difference
> between a signed object read by code that doesn't handle signatures, an
> object with no signature, one signed using an unknown algorithm, one signed
> using revoked keys, and one made with a deprecated algorithm. None of them
> should be trusted by verifying code. Signatures you trusted one day may not
> be trusted on the next day, but while they are trusted, they can be very
> useful.
>
> > If items in my collection need to refer to each other
>> refer *how*, precisely? `tag` is intended as a general "inclusion by
>> reference" mechanism, but there also exists the more specific `inReplyTo`
>> for when your object is in some way a response to another object.
>
> Consider an object that speaks about some other object. An example might
> be a Note identifying the author of some web page. The intent is neither to
> "include by reference" nor to "respond" to the web page. The intent is
> merely to provide some meta-data for the web page. I could list out many
> different motivations for one object including a reference to another, but,
> it probably isn't either useful or even possible to come up with an
> exhaustive list. This would argue for providing a simple general mechanism
> for making references (i.e. Annotations) and then allowing those
> References/Annotations to have types (i.e. tag, InReplyTo, about, like,
> dislike, etc.)
>
> bob wyman
>
>
> On Mon, Mar 13, 2023 at 5:31 AM a <a@trwnh.com> wrote:
>
>> > it says nothing about the interface for performing even basic CRUD
>> operations on those Collections. (e.g. CRUD = Create, Read, Update, Delete)
>>
>> i'm not sure why you would apply CRUD to Collections. we have Add and
>> Remove.
>>
>> > If I want to sign, or encrypt a Collection, or some or all of its
>> elements, I get no guidance from any of the existing Activity*
>> specifications. If I look around hard enough, I might stumble across the Verifiable
>> Credential Data Integrity <https://w3c.github.io/vc-data-integrity/> and
>> find in it some guidance on signing chunks of JSON-LD, but I'm not really
>> sure if anyone else would be able to understand such signed JSON-LD.
>>
>> yes, ActivityStreams and ActivityPub do not mandate any specific
>> authentication or verification or proof mechanism. if they had, they would
>> very quickly be outdated. i'm sure more work is ongoing with VCDI regarding
>> this general issue of verifiability and data integrity proofs, some
>> discussion of which can be found with FEP-8b32:
>> https://socialhub.activitypub.rocks/t/fep-8b32-object-integrity-proofs/2725
>> -- the problem of course is deciding on a cryptosuite. cryptosuite churn is
>> the biggest problem in general, as any proof you generate today will
>> probably soon be useless on account of no one knowing how to verify it in a
>> few years. see RsaSignature2017 as used in mastodon's implementation of the
>> old Linked Data Signatures draft, which is not even defined anymore since
>> it was formalized as RsaSignature2018, and even *that* is still a draft.
>>
>> > If items in my collection need to refer to each other
>>
>> refer *how*, precisely? `tag` is intended as a general "inclusion by
>> reference" mechanism, but there also exists the more specific `inReplyTo`
>> for when your object is in some way a response to another object.
>>
>> > how can I spend more time coding and less time digging through
>> discussion lists of standards groups?
>>
>> i'm not sure there's a good answer to this question. if you want to
>> implement a standard then you'll probably end up looking at either the
>> standard itself, or at some implementation guide or tutorial.
>>
>