Re: Including Security namespace terms in the Activity Streams 2.0 context document, take two

There was one other concern raised about whether adding *any* terms is
truly needed or is a good idea, given that it could simply entrench
the current usage of HTTP Signatures. Adding them at any point would
make it harder to remove them later.

For a related example, consider the use of `RsaSignature2017` in
implementations of Linked Data Signatures. The problem there is that
`RsaSignature2017` was actually finalized as `RsaSignature2018` (in
Security V2, at that!), so all current usage of `RsaSignature2017` is
actually non-compliant with JSON-LD. An analogous move to include a
term definition for `RsaSignature2017` would be counterproductive for
getting implementers to update their implementations to be compliant.

An additional concern pertains to the `Key` type/class. The Security
V1 context document actually defines it as `CryptographicKey` instead.
It was then deprecated entirely.

Yet another concern pertains to the `owner` property. Before `Key` was
deprecated, it would be expected to be used with `controller`, not
with `owner`; this is because `owner` was itself deprecated at some
intermediary point.

For these reasons, I would be -1 on including these terms in the AS2
context document. I think the energy would be better spent in
developing a migration plan to modernize the security protocols used
alongside AP, or otherwise developing a standard profile for security
intended for use alongside AP.

Received on Monday, 22 April 2024 00:56:34 UTC