FEP-521a: Representing actor's public keys

Standards Fediverse Enhancement Proposals
, ,
21

Update: #289 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

Adding this paragraph:

Actor object MUST be used as a controller document, as described in section 2.3 Controller Documents of Data Integrity specification.

This is merely a clarification, and doesn’t require changing existing implementations.

In other news, Hubzilla now supports FEP-521a

1 Like
22

Update: #324 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

Clarifying how invalid items in assertionMethod array should be processed, adding @fedify to implementations.

1 Like
23

Just as an FYI, the other representation is what’s standard in OAuth WG at IETF, and is how did:jwk encodes keys-- this later provides [backwards-compatible] interop with most contemporary (and older-but-still-supported) OIDC middleware, so MAY be useful for people down the road that are trying to implement AP on top of existing software with lots of users that use OIDC for everything (i.e. Log In With Google buttons).

But base58btc can be implemented in a few lines and is probably what I would pick until people start asking for the other. We can always write an extension-FEP making this multi-key-expression later, of course!

2 Likes
24

This FEP has been updated: #482 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

25

Controlled Identifiers is a W3C Recommendation now: Controlled Identifiers v1.0
I’ve made several minor changes in #603 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org, and I think it is done. Please submit your final comments!

26

Different public keys of the same actor MUST be identified using different fragment IDs.

This statement could be confusing in scenarios where fragment key IDs are not being used. For example, an actor could have multiple public keys where none of them use fragment ids or they might use a mix of fragment and non-fragment ids. The statement implies all keys MUST have a fragment id which isn’t consistent with the SHOULD recommendation for using fragment key ids in the previous sentence.

I think it would also be useful to provide a rationale for strongly recommending that the key id is based on the actor URI with a fragment. I understand this is the common pattern in the Mastoverse, but there are valid scenarios where this is not desirable (external key storage, for example).

1 Like
27

Is there a recommended method for adding a PGP public key to an actor?

1 Like
28

@stevebate What do you think about the following text:

Identifiers SHOULD be generated by appending a fragment identifier to the actor ID. That allows consumers to retrieve a public key and an associated actor object with a single HTTP request. If keys are identified using fragment identifiers, each key MUST have a unique fragment identifier.

Is it better?

1 Like
29

It depends on the purpose of a key:

  • If it is supposed to be used by a server to generate HTTP signatures or data integrity proofs, then I’d recommend to use the method described in this FEP. No multicodecs for PGP keys have been registered yet, but we can attempt to register one.
  • If it is supposed to be controlled by a user, but with a machine-readable cryptographic link to the actor, then FEP-c390: Identity Proofs might be used. In that case we would also need to register a multicodec, and create a cryptosuite specification (could be published in a FEP format).
  • If it is supposed to be controlled by a user, but a cryptographic link is not necessary, then it could be added to the actor document as a regular PropertyValue attachment, or a FEP-fb2a metadata entry.
30

@stevebate I added the text we discussed to the FEP several days ago: #605 - FEP-521a: Rephrase recommendations for constructing key IDs - fediverse/fep - Codeberg.org

Adding new requirements today: #606 - FEP-521a: Update proposal - fediverse/fep - Codeberg.org

31

@bashrc I opened an issue about registering a codec for PGP public keys: PGP public keys · Issue #381 · multiformats/multicodec · GitHub