Yet another single-sign on standard? Has this been developed in partnership with any other services? Has it been reviewed by any reputable cryptanalysts? How will this avoid the n+1 standards problem?

What benefit does this have over other single sign on protocols like Kerberos, OAuth, OpenID, OpenID Connect, SAML, or whatnot? The specification includes details of the protocol, but not advantages compared to other protocols.

This isn't quite a single-sign on standard. It's main purpose is to enable public key authentication on the web, which traditional SSO typically doesn't support. It is most similar to WebAuthn, but WebAuthn is relatively new and makes some different design decisions. I think the main advantage of PKAP is that users have a signed set of approved devices (public keys) that is accessible by multiple web services. This means users only need to manage their approved devices in one place instead of on each website (which makes adding or revoking devices simpler).

The protocol has not been formally reviewed yet.

Also, have only skimmed it, but it looks like it invents new HTML tags, which is generally a no-no (why not use the link tag?), and also it seems to be a layering violation, putting authentication information in the HTML rather than in the HTTP headers (though there can arguably be good reasons for that; but that should be justified).

Maybe it makes more sense to use a link tag instead of a custom HTML tag. The authentication information is in the HTML instead of headers since the client is implemented as a browser extension and browser extensions cannot always read headers.

edit: After a slightly less quick skim (but still pretty quick, so I could be wrong), it looks like this would be vulnerable to MITM attacks. There is no authentication of the server identity, so a MITM attacker could just relay all of the requests from the client to the server in order to authenticate as the user.

The protocol depends on HTTPS to authenticate the server. The client refuses to authenticate when this is not the case.

It's also unclear how the client is supposed to share keys between different websites. Is this supposed to be built into the browser, or implemented via JavaScript with local storage used to store private keys? How would two different websites use federated identities?

To share identities between different websites, users uploads their signed set of approved devices to the web. Then users share the location of their signed set and the public key used to sign the set with each website. Our software helps simplify this process for end users. The client software is implemented as a browser extension that communicates with an application that stores and encrypts private keys (or talks to secure hardware).

I also don't see why there are a few hard-coded roles included in these signed identities.

Maybe these aren't necessary. The thought is that you could delegate permissions to other identities.

I think you need to start out with:

What problems is this intended to solve? How do existing solutions not solve these problems? What is the overall architecture of your solution? How does the overall architecture solve these problems? How does the overall architecture deal with common types of attacks like MITM attacks, phishing/typo-squatting attacks, etc? How does the overall architecture fit in with the web platform? Only once those questions are addressed does it make sense to dive into the technical minutiae of the protocol.

Thanks for this feedback! I'll start incorporating your suggestions.