keyoxide/keyoxide-web
26
329
Fork
You've already forked keyoxide-web
39

UI Disclaimer Exclaiming that No Claims are Being Made Regarding OpenPGP User IDs #249

Open
opened 2025年07月22日 16:55:55 +02:00 by j-simonson · 0 comments

Proposal

It's been suggested that the Keyoxide UI output be enhanced to include a disclaimer regarding the OpenPGP user IDs displayed. The disclaimer being that no claim is being made or should be inferred regarding the validity of the user IDs themselves.

Discussion

Ariadne Claims are made between a Master Key and a digital asset. And by direct association between User IDs under that Master Key and those digital assets.

To the uninitiated or casual observer, the claims made might be seen to extend (at least to some degree) to the User ID themselves as digital assets in their own right. That is, that in some way the User IDs have been vetted, despite the fact that the UI displays no check marks by the User IDs, just simply by the mere fact that User IDs are displayed.

Those entrenched in OpenPGP understand that the validity one assigns to a User ID is ultimately the responsibility of the individual utilizing that User ID. Individuals may of course factor in vetting done elsewhere while taking into consideration the trustworthiness of that vetting, but they themselves make the final determination.

Keyoxide limits its default key lookup to keys.openpgp.org and WKDs. keys.openpgp.org conducts an initial test of User ID email ownership upon key upload to its servers. WKD drafted best practices state a similar practice must be followed by WKDs. WKDs at large may or may not do so however. Keyoxide itself does no vetting of User IDs, and provides no oversight wrt to keys.openpgp.org or WKDs at large. And thus in truth, should make no claims regarding the User IDs. Keyoxide to its credit does practice clearly denoting the source of the key material.

User IDs are in fact, in the Keyoxide context, just convenient aliases for the Master Key. Aliases under which claims may be further grouped and divided.

Who is Keyoxide's audience? What is their level of competence in this context? One does not want to clutter the landscape with extra verbiage when it maybe unnecessary. Disclaimers and legal documents as it is, tend to be way too long and just get longer with age. However, if our friend who knows nothing of OpenPGP and security practices, gets the link https://keyoxide.org/john.doe%40jane.doe.com, what are they to make of it? But do they in fact really know nothing? If they don't trust or really know their source, they may not trust the link either. Or, how likely are they to just independently lookup john.doe@jane.doe.com without first consulting with John or Jane prior to trusting the information retrieved.

Reference

Further discussion can be found @ #keyoxide:matrix.org.

keyoxide/keyoxide-web#248
keyoxide/keyoxide-web#81
keyoxide/keyoxide-web#81#issuecomment-187173
keyoxide/keyoxide-web#81#issuecomment-5936170
https://gitlab.com/keys.openpgp.org/hagrid/-/issues/180

### Proposal It's been suggested that the Keyoxide UI output be enhanced to include a disclaimer regarding the OpenPGP user IDs displayed. The disclaimer being that no claim is being made or should be inferred regarding the validity of the user IDs themselves. ### Discussion Ariadne Claims are made between a Master Key and a digital asset. And by direct association between User IDs under that Master Key and those digital assets. To the uninitiated or casual observer, the claims made might be seen to extend (at least to some degree) to the User ID themselves as digital assets in their own right. That is, that in some way the User IDs have been vetted, despite the fact that the UI displays no check marks by the User IDs, just simply by the mere fact that User IDs are displayed. Those entrenched in OpenPGP understand that the validity one assigns to a User ID is ultimately the responsibility of the individual utilizing that User ID. Individuals may of course factor in vetting done elsewhere while taking into consideration the trustworthiness of that vetting, but they themselves make the final determination. Keyoxide limits its default key lookup to keys.openpgp.org and WKDs. keys.openpgp.org conducts an initial test of User ID email ownership upon key upload to its servers. [WKD drafted best practices state a similar practice must be followed by WKDs](https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service#name-security-considerations). WKDs at large may or may not do so however. Keyoxide itself does no vetting of User IDs, and provides no oversight wrt to keys.openpgp.org or WKDs at large. And thus in truth, should make no claims regarding the User IDs. Keyoxide to its credit does practice clearly denoting the source of the key material. User IDs are in fact, in the Keyoxide context, just convenient aliases for the Master Key. Aliases under which claims may be further grouped and divided. Who is Keyoxide's audience? What is their level of competence in this context? One does not want to clutter the landscape with extra verbiage when it maybe unnecessary. Disclaimers and legal documents as it is, tend to be way too long and just get longer with age. However, if our friend who knows nothing of OpenPGP and security practices, gets the link [https://keyoxide.org/john.doe%40jane.doe.com](), what are they to make of it? But do they in fact really know nothing? If they don't trust or really know their source, they may not trust the link either. Or, how likely are they to just independently lookup [john.doe@jane.doe.com]() without first consulting with John or Jane prior to trusting the information retrieved. ### Reference Further discussion can be found @ [#keyoxide:matrix.org](https://matrix.to/#/!dEfJkFpQpwvbzcegRX:matrix.org/$vSOh3eNUPbzu3AATvfgusdZ40AYQT8P_eJkUe5GzWMc?via=matrix.org&via=mackenba.ch&via=tchncs.de). ### Related keyoxide/keyoxide-web#248 keyoxide/keyoxide-web#81 [keyoxide/keyoxide-web#81#issuecomment-187173](https://codeberg.org/keyoxide/keyoxide-web/issues/81#issuecomment-187173) [keyoxide/keyoxide-web#81#issuecomment-5936170](https://codeberg.org/keyoxide/keyoxide-web/issues/81#issuecomment-5936170) https://gitlab.com/keys.openpgp.org/hagrid/-/issues/180
Sign in to join this conversation.
dev
main
dev
redesign-2023
add-logging
5.1.0
5.0.1
5.0.0
5.0.0-rc.1
4.2.7
4.2.6
4.2.5
4.2.4
4.2.3
4.2.2
4.2.1
4.2.0
4.1.1
4.1.0
4.0.2
4.0.1
4.0.0
3.6.4
3.6.3
3.6.2
3.6.1
3.6.0
3.5.2
3.5.1
3.5.0
3.4.18
3.4.17
3.4.16
3.4.15
3.4.14
3.4.13
3.4.12
3.4.11
3.4.10
3.4.9
3.4.8
3.4.7
3.4.6
3.4.5
3.4.4
3.4.3
3.4.2
3.4.1
3.4.0
3.3.1
3.3.0
3.2.0
3.1.1
3.1.0
3.0.4
3.0.3
3.0.2
3.0.1
3.0.0
2.5.0
2.4.2
2.4.1
2.4.0
2.3.4
2.3.3
2.3.2
2.3.1
2.3.0
2.2.8
2.2.7
2.2.6
2.2.5
2.2.4
2.2.3
2.2.2
2.2.1
2.2.0
2.1.1
2.1.0
2.0.2
2.0.1
2.0.0
2.0.0-rc.3
2.0.0-rc.2
2.0.0-rc.1
1.0.0
0.4.0
0.3.1
0.3.0
0.2.1
0.2.0
0.1.0
Labels
Clear labels
bug
Something is not working

Archived

contribution welcome
Contributions are very welcome, get started here

Archived

enhancement
New feature

Archived

good first issue
Interested in contributing? Get started here.

Archived

Contribution welcome
Get started contributing here
Good first issue
Good if you are new to the project or to open source contributions
Impact
External
Affects the people using the project
Impact
Internal
Affects on the people working on the project
Priority
Critical
Work on right now
Priority
High
Work on at earliest convenience
Priority
Low
Work on in spare time
Priority
Medium
Work on regularly
Review
Duplicate
Already exists
Review
Off Topic
Does not fall within the scope of the repo/project
Status
Backlog
Is not being worked on yet
Status
Blocked
Is waiting on something or someone
Status
Completed
Is done
Status
In Progress
Is being worked on
Status
Investigating
Is waiting on research or questions
Status
Needs Decision
Is waiting on a decision by the devs/contributors
Status
Needs Info
Is waiting on additional information before it can be solved
Status
Needs Triage
Is new issue that needs reviewing
Status
Testing
Is being checked and verified
Status
Waiting For Review
Is waiting on reviewers to approve
Status
Won't Fix
Won't be fixed
Type
Bug
Related to something not working as intended
Type
CI
Related to continuous integration
Type
Documentation
Related to documentation
Type
Enhancement
Related to a new feature or an improved one
Type
New Claim
Related to a new identity claim/proof
Type
Security
Related to security
Type
Tests
Related to code tests
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
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/keyoxide-web#249
Reference in a new issue
keyoxide/keyoxide-web
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?