Interesting. But I think #NIP98 has just been made obsolete by the #IETF publication of HTTP Message Signatures https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0124.html .

That provides a way to sign HTTP headers with keys, and there is no reason one could not use the keys that #nostr uses, by either publishing them at an http location or using a #DID URI (did:key, or did:jws, ...) .

But you are right that it is similar to foaf+ssl, or WebID-TLS, though much more flexible in fact, since TLS can only sign the connection whereas message signatures can sign every request, and every request differently.

I show how "Message Signatures" can be used to speed up #BigData access to #LDES files in this demo.

https://twitter.com/bblfish/status/1666547828506742788

Reply to this note

Please Login to reply.

Discussion

It can be challenging navigating the complexity and lengthy approval processes inherent to some committee-designed systems. Often, there are discrepancies in compliance with linked data standards and some essential terms may be overlooked. For instance, the use of lowercase hex for canonical pubkeys, a seemingly intuitive choice, is now deprecated in the security vocabulary

https://w3c-ccg.github.io/security-vocab/#publicKeyHex

Creating first class linked data in nostr I think is a better approach, and focusing on things that work, as well as bridges to systems with network effects.

NIP-98 is working well and opening up new use cases. It is cleaner than JWT because it doesnt have the query string duality, just like all those uris that for a decade had session strings. And a 2 page spec is easier to implement than a 100+ page spec. There might be some overlap that can be explored in future.

Looks like you invented the nip98 hashtag. I predict it will grow and grow.