Re: Verifiable credentials decentralized status

Hi,

I have now deepen my reflections on the draft and here is what comes

To follow up the preceding message, the suggested specification does not
enable revocation in a privacy preserving way, having the obligation to
disclose the did of the holder to the issuer. That said I think revocation
is not mandatory to see a working framework of statuses. (
https://github.com/malach-it/vc-decentralized-status/blob/main/SPECIFICATION.md#7-about-revocation
)

The draft states about a way to have a decentralized way to store statuses.
It helps to derive it into a token that is solvable given a list of
possible statuses and a secret (may the secret be public). The suggested
way of seeing statuses would also help to store multiple statuses in a
single token not increasing its byte size. This way, it enables to see
selective disclosure without disclosing the overall number of claims (
https://github.com/malach-it/vc-decentralized-status/blob/main/SPECIFICATION.md#83-choosing-multiple-statuses).
Some of those properties may be interesting for some use cases with
identity information status concerns.

I made a working implementation of it in an open source project I am
working on (
https://github.com/malach-it/boruta_auth/blob/master/lib/boruta/verifiable_credentials.ex#L42
).

I am not sure it is to be considered to be one of the group work items, but
it can be interesting for people to have a look seen the properties of the
resulting tokens and their possible usage.

Thank you for reading me so far.

With care,
Pascal

On Thu, Jul 11, 2024 at 6:48 AM Pascal Knoth <pascal@malach.it> wrote:

> 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
>
>

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

With care from Paris, France