[Atp] Re: Basic Objectives/Requirements

[Bryan Newbold <[e-mail]>]

On Wed, Nov 12, 2025 at 2:09 PM Orie <[e-mail]> wrote:

> ```
> *Note that neither the signature itself nor the signed commit indicate
> either the type of key used (curve type), or the specific public key used.
> That information must be fetched from the account's DID document. With key
> rotation, verification of older commit signatures can become ambiguous. The
> most recent commit should always be verifiable using the current DID
> document.* *This implies that a new repository commit should be created
> every time the signing key is rotated. Such a commit does not need to
> update the data CID link.*
> ```
>
> In the context of the DID standard, there is no way to know "which key is
> the current signing key".
> A DID Document may have many different keys, each for different purposes
> (assertionMethod, authentication)... and they can come in all different
> kinds of formats.
>

Indeed, DID documents are flexible. But there is a clear way to pull out
the specific key used for AT repo signing, described in Section 2.3:

---
The signing key for repository commits is specified within the DID
document's verificationMethod array.  The key entry must have an id field
ending in #atproto.  When multiple possible verification methods are
present, implementations must use the first valid entry and ignore
subsequent ones.  The public key must be encoded using the
publicKeyMultibase format as specified in [CONTROLLEDID].  The signing key
must use one of the signing algorithms described in Section 2.6.2.
---

The text about not indicating the specific key is getting at the fact that
the information in the DID document can change over time. There is not
(currently) a fingerprinting or versioning system that might clarify that
better.

Other parts of AT currently use additional keys. For example, the
"labeling" moderation mechanism (which would not be in scope under the
initial charter, but could be included later down the line) uses a
verificationMethod with id '#atproto_label'. Details at
https://atproto.com/specs/label#signatures

If we consider "account" to be equivalent to the JOSE/COSE concept of
> "iss", then much of what we are trying to do with commit verification could
> have been:
>
> (account) -> (public keys)
> (signed commit) -> (account and key used to verify)
> ...
> (iss) -> application/jwk-set+json / application/cose-key-set ... ( current
> "account signing keys" )
> (iss + kid) -> application/jwk+json / application/cose-key    ... ( the
> specific key that was actually used to sign )
> ...
>

Yup, there is a strong analogy to "iss". The XRPC component of AT (HTTP
APIs) has a concept of "inter-service auth" using JWTs, and it includes a
DID with fragment to indicate a service type. There is a fuzzy concept
there about connecting typed service endpoints (eg, a URL) to a typed
verification method (eg, a public key). Details:
https://atproto.com/specs/xrpc#inter-service-authentication-jwt

--bryan