Re: Verifiable credentials decentralized status

Hi Manu,

Thank you for the time you took reading the possible specification draft
and for your feedback which I'll try here to reply to.

About decentralization

In the idea of the specification, I speak about decentralized storage, the
decentralized check may not be possible. The check of the status may not be
decentralized since only the issuer have real-time information about a
holder's credential status. Enforcing the verifier to contact the issuer is
made to have eventual real-time information. That said, there is still no
interface to have revocation and as you said by doing this, the issuer may
have a holder reference which would impact his privacy. I think taking the
revocation apart would help to keep the privacy but remove the ability to
have real-time status, thinking about JWTs which have the same kind of
property the specification may still be interesting. Note that while the
issuer checks the status, it has no information about neither the holder
nor the credential at stake (see the privacy section of the draft).

About the flow

You are right, the issuer crafts status tokens along with the credentials
given to the holder. For the presentation, the verifier contacts the issuer
with the status tokens to verify them. The privacy preservation comes from
the fact that no credential information is sent for the status verification.

About privacy

The verifier would only have information about the issuer's location but
none about the holder since there is no credential information at stake in
the verification process. Thinking more about revocation, we can take the
example of passport checks when you travel, the states are contacted with
the holder's information. With the suggested specification, the proof (the
holder did) and the credential type would be needed for the verification. I
am not sure we can do better regarding this issue than the actual way for
that kind of credential check.

Hoping it better helps to get the idea of the suggested specification.

Once more thank you for your time.

Have a great morning / afternoon / evening wherever you are.

With care,

Le mer. 10 juil. 2024 à 15:21, Manu Sporny <msporny@digitalbazaar.com> a
écrit :

> On Sat, Jul 6, 2024 at 6:15 AM Pascal Knoth <pascal@malach.it> wrote:
> >> I am Pascal Knoth, an independent worker,
>
> Hi Pascal, thank you for the work you are doing on revocation
> mechanisms for VCs. :)
>
> We definitely need better privacy-preserving mechanisms for doing
> revocation. I read through your spec multiple times and have a few
> observations and questions.
>
> The use of HOTP is interesting, but I can't quite understand what it
> is doing. My expectation going into the specification was that this
> was a privacy preserving status checking mechanism that would enable
> the holder to assert their status in a way that is decentralized and
> didn't require interactions with the issuer. After reading the spec, I
> feel that my assumptions are wrong, but don't know which ones.
>
> I gather that the issuer has a secret and they use that to issue some
> sort of HOTP-based token, presumably to the holder? The holder then
> takes that token and gives it to a verifier? The verifier then uses
> that token and asks the issuer if its still valid?
>
> If that's the flow, doesn't the verifier uniquely identify the holder
> when the check is performed by the issuer? Doesn't this result in even
> more "bytes transmitted over the wire" than a single status bit in a
> bitstring?
>
> As you can see, I'm struggling to understand the goals and advantages
> of the specification. Can you help me understand where I'm going wrong
> above? We are very interested in more decentralized,
> privacy-preserving status mechanisms for the VC ecosystem! Thanks
> again for the time and care you put into the specification.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>


-- 
Pascal Knoth - malachit
phone 0033 630739479
https://io.malach.it

With care from Paris, France

Received on Thursday, 11 July 2024 04:49:06 UTC