Re: Sirraya One: A Web based platform to create DID and Issue VCs

I’m fully on board with collaboration. To clarify, I will also use standard
JWTs in my model, they work well and people understand them. In my
architecture, JWTs are purely for session and IAM purposes at the data and
storage layer. All data operations handle only fully encrypted payloads,
and only devices or clients capable of generating account-bound WebAuthn
credentials can decrypt them with the master key decrypted using the PRF
extension result.

JWTs in my system follow the usual pattern {iss: "mydomain", sub:
"userInServicePseudonym", exp: "ts", aud: "domain"}. What I’m exploring
further is zero-knowledge authorization between two services:
– The depending client generates a public/private key pair and stores the
private key locally (for example in Web Storage).
– It then redirects to my authorization endpoint (served client-side code
handles the logic) with scopes and the client’s public key.
– If the user authorizes, the decrypted data on my side is re-encrypted
using that public key.
– The transfer is confirmed through a JWT or JWT-VC (I don’t fully
understand the difference when it comes to verifying the issuer with a
public key) sent in the callback, verifiable via a public key under
.well-known/.

The recipient can then fetch and decrypt the payload client-side, or my web
app client can post the public-key-encrypted data directly to an endpoint
you specify, which the user can access with their JWT from your service.

This pattern keeps backend verification simple, signing and verifying JWTs
works as usual. I think the important part is what happens before issuing
the JWT and what the JWT actually represents. As long as it only carries an
in-service pseudonymous ID, it already fits well for zero-knowledge
services.

su 9.11.2025 klo 9.56 Amir Hameed (amsaalegal@gmail.com) kirjoitti:

> That’s a great perspective, and I fully agree with your reasoning —
> especially your use of the PRF extension and pseudonym-bound keys for
> usernameless WebAuthn flows.
>
> Our prototype approaches the same trust model from a slightly different
> angle — we’re focusing on transition usability for legacy web systems. Many
> services can’t yet adopt native WebAuthn or PRF extensions, so we’re
> exploring a bridge layer where passphrase-derived keys can issue JWT-VCs
> and interface with standard JWT authentication without sacrificing user
> control.
>
> Long-term, we plan to support WebAuthn-native credentials (PRF-based
> derivations included) and integrate verifiable personhood credentials to
> help address the Sybil-resistance problem you mentioned. I completely agree
> this is one of the biggest open challenges — combining privacy-preserving
> uniqueness with service fairness.
>
> I’d love to collaborate or align our prototype with your WebAuthn approach
> — perhaps we can test interoperability between your PRF-based master-seed
> model and our VC issuance/verification pipeline.
>
> On Sun, 9 Nov 2025 at 1:13 AM, Jori Lehtinen <lehtinenjori03@gmail.com>
> wrote:
>
>> Sure have and it no doubt solves that, but it’s not a web standard and
>> isn’t accessible through any Web API only as a third-party solution, and,
>> as I understand it, Web Standards is what this mailing list is about.
>>
>> la 8.11.2025 klo 9.22 ip. Alan Karp <alanhkarp@gmail.com> kirjoitti:
>>
>>> Have you looked at https://self.xyz/ for Sybil resistance?
>>>
>>> --------------
>>> Alan Karp
>>>
>>>
>>> On Sat, Nov 8, 2025 at 10:41 AM Jori Lehtinen <lehtinenjori03@gmail.com>
>>> wrote:
>>>
>>>> Hi! It’s great that you’re building this, I assume it’s aimed at users
>>>> who prefer a passphrase-based system. Or I’d like to understand what
>>>> specific problem it solves, since WebAuthn passkeys already provide
>>>> passwordless strong authentication and zero-knowledge credential-bound key
>>>> derivation through the PRF extension.
>>>>
>>>>
>>>> In my own projects, I’m implementing a usernameless WebAuthn flow where
>>>> multiple credential pseudonyms can be bound to a single in-service
>>>> pseudonym ID. I use the PRF to encrypt and then back up a random Master
>>>> Seed to the cloud. All user data is encrypted with this master key, which
>>>> is itself encrypted with the prf extension result. You can attach as many
>>>> credentials as you want to an account, but data can only be read using a
>>>> key derived from the master seed decrypted by the credential-bound key.
>>>>
>>>>
>>>> I consider this a complete zero-knowledge identity system, durable and
>>>> requiring no user action. The remaining challenge is Sybil resistance and
>>>> fraud prevention. That’s the last major problem to solve. I’d like to see
>>>> focus on how to make zero-knowledge systems respect service providers, by
>>>> preventing users from creating new passkey or passphrase-bound credentials
>>>> after each free-trial.
>>>>
>>>>
>>>> This issue mainly affects services where users only consume content and
>>>> don’t care about losing account data, but it’s still significant. I’ve
>>>> previously suggested that national eID providers could help here. Another
>>>> option is to use verified, hard-to-acquire documents, such as passports or
>>>> personal IDs,  integrated into the passkey registration flow via an
>>>> extension that requires proof of personhood through document or eID
>>>> signatures. This proof should be a verifiable credential, allowing
>>>> anonymous per-person business logic. After all, each new disposable account
>>>> costs the service provider resources , and by extension, the environment,
>>>> while also limiting a provider’s right to decide how much they give away
>>>> for free.
>>>>
>>>> la 8.11.2025 klo 6.24 ip. Amir Hameed <amsaalegal@gmail.com> kirjoitti:
>>>>
>>>>> Hello Everyone
>>>>>
>>>>> I'm excited to share a prototype from Sirraya Labs that addresses key
>>>>> adoption challenges we've been discussing in this group. We've been working
>>>>> on practical bridges between decentralized identity infrastructure and
>>>>> legacy web systems.
>>>>>
>>>>> Prototype Overview:
>>>>> Our platform focuses on usability and interoperability while
>>>>> maintaining security:
>>>>>
>>>>>    -
>>>>>
>>>>>    Key Management & Recovery: Implements a passphrase-based encrypted
>>>>>    key derivation system, providing familiar recovery mechanisms while
>>>>>    preserving user control
>>>>>    -
>>>>>
>>>>>    Standards-Based VC issuance: Full support for Verifiable
>>>>>    Credentials with JWT-VC format
>>>>>    -
>>>>>
>>>>>    Practical Authentication: Generates standards-compliant JWT tokens
>>>>>    for immediate integration with existing session management and
>>>>>    authentication systems
>>>>>    -
>>>>>
>>>>>    Web Technology Bridge: Designed specifically to help legacy
>>>>>    systems gradually adopt decentralized identity patterns
>>>>>
>>>>> Technical Approach:
>>>>>
>>>>>    -
>>>>>
>>>>>    Client-side key generation with passphrase-based encryption
>>>>>    -
>>>>>
>>>>>    Support for did:key and did:web methods initially
>>>>>    -
>>>>>
>>>>>    JWT-VC issuance and verification pipeline
>>>>>    -
>>>>>
>>>>>    RESTful APIs for easy integration
>>>>>
>>>>> We're particularly interested in feedback on our approach to key
>>>>> recovery and the JWT bridging pattern, as we believe these are critical for
>>>>> mainstream adoption.
>>>>>
>>>>> The prototype is live at: https://one.sirraya.org
>>>>>
>>>>> We'd appreciate any technical feedback, security considerations, or
>>>>> interoperability thoughts from this group. We're also keen to collaborate
>>>>> on use cases and standardization efforts.
>>>>>
>>>>> Looking forward to the discussion.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Amir Hameed Mir
>>>>>
>>>>> Founder, Sirraya Labs
>>>>>
>>>>