ASP discoverability #4

New Issue

Open

opened 2023-07-27 04:38:27 +00:00 by tyy · 0 comments

tyy commented

2023-07-27 04:38:27 +00:00

The issue

The current prototype of the Ariadne signature profile specification is notably lacking any method of discovering profiles outside of fetching via a raw fingerprint. This contrasts with the current openpgp method, which allows a user to just type an email into https://keyoxide.org and magically get a profile. Some form of simple discoverability such as email or domain would be nice to integrate with ASPs.

How it works now

Currently, we have openpgp key profiles, and openpgp signature profiles. Openpgp signature profiles have no discoverability whatsoever, you just have to rely on being sent or finding the signature text blob somewhere else. Openpgp key profiles currently can be discovered through HKP-compatible keyservers, such as hkps://keys.openpgp.org. Keyoxide-web currently uses hkps://keys.openpgp.org as a sensible default for searching for a key by email. Openpgp key profiles can also currently be discovered through Web Key Directory (WKD). This allows using the domain-part of an email, and asking it directly for the openpgp key. This is nicer than relying on a centralized keyserver, but also is not largely supported, unless someone hosts their own email.

Some ideas of my own

This issue is kind of just meant to get a discussion started around the best way to do discoverability, so below are some ideas of my own, based on how it previously worked and what I personally think it should feel like, but are in no way the single only best way to do it.

Search by email

ASPE servers are the ASP equivalent of an HKP server, which means they could also support searching for a profile by email just like HKP servers. An endpoint could be added to query one or more profiles that include the given email address. This does introduce some issues that need to be discussed however surrounding implementation:

Should there be an opt-in system for email discovery? It might be nice to be able to specify "no, this profile should only be discovered by a fingerprint" if someone wants to advertise their email with the profile but not the other way around
- I would assume this would be a good idea, and help bring over one of the main benefits of openpgp signature profiles to ariadne signature profiles: the ability to distribute multiple profiles in multiple contexts, but both having the same attached email address
Email verification would likely be necessary if profiles are discoverable by emails, and because of this, how should it be implemented? Should the spec be specific (such as introducing an email verification endpoint) or should it just be left as a recommended implementation detail?
- I personally think that it would be a good idea to add (optional) email verification for ASPE servers into the spec itself. This could be like adding a response to "create" or "update" request JWS responses indicating that email verification is necessary, and maybe also a standardized endpoint for email verification (along the lines of GET /.well-known/aspe/verify?token={token} perhaps, or at least something of that variety).

Search by domain

This has been talked about for a while (even before ASPs, #1), and could be nice to implement for ASPs. The idea is that someone could host their own profile on their own domain, without any need for an ASPE server or any other middleman. There are many ways this could be done, but I believe the simplest would be to support something along the lines of GET /.well-known/aspe/id/default. This could be easily served using a static filesystem or any reverse proxy, and would allow fetching a profile from a domain name. For example, I could enter tyyy.me into https://keyoxide.org, and it could make a request to https://tyyy.me/.well-known/aspe/id/default and parse the provided profile.

# The issue The current prototype of the [Ariadne signature profile](https://ariadne.id/related/ariadne-signature-profile-0/) specification is notably lacking any method of discovering profiles outside of fetching via a raw fingerprint. This contrasts with the current openpgp method, which allows a user to just type an email into https://keyoxide.org and magically get a profile. Some form of simple discoverability such as email or domain would be nice to integrate with ASPs. # How it works now Currently, we have openpgp key profiles, and openpgp signature profiles. Openpgp signature profiles have no discoverability whatsoever, you just have to rely on being sent or finding the signature text blob somewhere else. Openpgp key profiles currently can be discovered through HKP-compatible keyservers, such as hkps://keys.openpgp.org. Keyoxide-web currently uses hkps://keys.openpgp.org as a sensible default for searching for a key by email. Openpgp key profiles can also currently be discovered through Web Key Directory (WKD). This allows using the domain-part of an email, and asking it directly for the openpgp key. This is nicer than relying on a centralized keyserver, but also is not largely supported, unless someone hosts their own email. # Some ideas of my own This issue is kind of just meant to get a discussion started around the best way to do discoverability, so below are some ideas of my own, based on how it previously worked and what I personally think it should feel like, but are in no way the single only best way to do it. ## Search by email ASPE servers are the ASP equivalent of an HKP server, which means they could also support searching for a profile by email just like HKP servers. An endpoint could be added to query one or more profiles that include the given email address. This does introduce some issues that need to be discussed however surrounding implementation: 1. Should there be an opt-in system for email discovery? It might be nice to be able to specify "no, this profile should only be discovered by a fingerprint" if someone wants to advertise their email with the profile but not the other way around - I would assume this would be a good idea, and help bring over one of the main benefits of openpgp signature profiles to ariadne signature profiles: the ability to distribute multiple profiles in multiple contexts, but both having the same attached email address 2. Email verification would likely be necessary if profiles are discoverable by emails, and because of this, how should it be implemented? Should the spec be specific (such as introducing an email verification endpoint) or should it just be left as a recommended implementation detail? - I personally think that it would be a good idea to add (optional) email verification for ASPE servers into the spec itself. This could be like adding a response to "create" or "update" request JWS responses indicating that email verification is necessary, and maybe also a standardized endpoint for email verification (along the lines of `GET /.well-known/aspe/verify?token={token}` perhaps, or at least something of that variety). ## Search by domain This has been talked about for a while (even before ASPs, #1), and could be nice to implement for ASPs. The idea is that someone could host their own profile on their own domain, without any need for an ASPE server or any other middleman. There are many ways this could be done, but I believe the simplest would be to support something along the lines of `GET /.well-known/aspe/id/default`. This could be easily served using a static filesystem or any reverse proxy, and would allow fetching a profile from a domain name. For example, I could enter `tyyy.me` into https://keyoxide.org, and it could make a request to https://tyyy.me/.well-known/aspe/id/default and parse the provided profile.

👍 1

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: keyoxide/project#4

There is no content yet.