A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"ostatus": "http://ostatus.org#",
"atomUri": "ostatus:atomUri",
"inReplyToAtomUri": "ostatus:inReplyToAtomUri",
"conversation": "ostatus:conversation",
"sensitive": "as:sensitive",
"toot": "http://joinmastodon.org/ns#",
"votersCount": "toot:votersCount",
"litepub": "http://litepub.social/ns#",
"directMessage": "litepub:directMessage"
}
],
"id": "https://infosec.exchange/users/estark/statuses/110295994936922518",
"type": "Note",
"summary": null,
"inReplyTo": null,
"published": "2023-05-01T23:22:01Z",
"url": "https://infosec.exchange/@estark/110295994936922518",
"attributedTo": "https://infosec.exchange/users/estark",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/estark/followers"
],
"sensitive": false,
"atomUri": "https://infosec.exchange/users/estark/statuses/110295994936922518",
"inReplyToAtomUri": null,
"conversation": "tag:infosec.exchange,2023-05-01:objectId=61859222:objectType=Conversation",
"content": "<p>The (very early stage) draft of Merkle Tree Certificates is worth a read if you haven't already: <a href=\"https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" translate=\"no\"><span class=\"invisible\">https://www.</span><span class=\"ellipsis\">ietf.org/id/draft-davidben-tls</span><span class=\"invisible\">-merkle-tree-certs-00.html</span></a></p><p>The idea is to store domain name<->public key bindings in a Merkle tree, mirrored by browser vendors or other designated entities to clients and other interested parties. TLS servers are authenticated via a proof of membership in one of these Merkle trees, instead of via a bunch of signatures in an X.509 certificate chain -- which are huge in a postquantum world. This new form of authentication only works for certain types of clients and certain types of situations, so the whole thing falls back to traditional X.509 certificate chains otherwise. You can think of it as a PKI designed from scratch, with CAs and CT smooshed into one system, as an optimization layer on top of today's web PKI.</p><p>The main motivation is postquantum cryptography; PQ signatures are huge and this scheme allows a client to verify a domain name <-> public key association with 0 signatures. The Merkle tree proof is no bigger in a PQ world. There are lots of other interesting properties that MTCs lets us explore too, like being able to negotiate trust anchors -- that is, a client can signal which CAs it supports and the server can authenticate itself in a way that works with those supported CAs. In contrast today a server has to configure a single certificate to work with all clients it wants to support. This part isn't fully fleshed out yet but it's exciting. It's a great time to give feedback on the draft.</p><p>All credit to my colleagues David Benjamin and Devon O'Brien!</p>",
"contentMap": {
"en": "<p>The (very early stage) draft of Merkle Tree Certificates is worth a read if you haven't already: <a href=\"https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html\" target=\"_blank\" rel=\"nofollow noopener noreferrer\" translate=\"no\"><span class=\"invisible\">https://www.</span><span class=\"ellipsis\">ietf.org/id/draft-davidben-tls</span><span class=\"invisible\">-merkle-tree-certs-00.html</span></a></p><p>The idea is to store domain name<->public key bindings in a Merkle tree, mirrored by browser vendors or other designated entities to clients and other interested parties. TLS servers are authenticated via a proof of membership in one of these Merkle trees, instead of via a bunch of signatures in an X.509 certificate chain -- which are huge in a postquantum world. This new form of authentication only works for certain types of clients and certain types of situations, so the whole thing falls back to traditional X.509 certificate chains otherwise. You can think of it as a PKI designed from scratch, with CAs and CT smooshed into one system, as an optimization layer on top of today's web PKI.</p><p>The main motivation is postquantum cryptography; PQ signatures are huge and this scheme allows a client to verify a domain name <-> public key association with 0 signatures. The Merkle tree proof is no bigger in a PQ world. There are lots of other interesting properties that MTCs lets us explore too, like being able to negotiate trust anchors -- that is, a client can signal which CAs it supports and the server can authenticate itself in a way that works with those supported CAs. In contrast today a server has to configure a single certificate to work with all clients it wants to support. This part isn't fully fleshed out yet but it's exciting. It's a great time to give feedback on the draft.</p><p>All credit to my colleagues David Benjamin and Devon O'Brien!</p>"
},
"attachment": [],
"tag": [],
"replies": {
"id": "https://infosec.exchange/users/estark/statuses/110295994936922518/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/estark/statuses/110295994936922518/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/estark/statuses/110295994936922518/replies",
"items": []
}
},
"likes": {
"id": "https://infosec.exchange/users/estark/statuses/110295994936922518/likes",
"type": "Collection",
"totalItems": 120
},
"shares": {
"id": "https://infosec.exchange/users/estark/statuses/110295994936922518/shares",
"type": "Collection",
"totalItems": 76
}
}