[Openid-specs-ab] Verifiable presentation question

[Nat Sakimura]

On Sat, May 15, 2021 at 2:19 AM David Chadwick <
d.w.chadwick at verifiablecredentials.info> wrote:

>
> On 14/05/2021 17:51, Nat Sakimura wrote:
>
>
>
> On Sat, May 15, 2021 at 12:19 AM David Chadwick <
> d.w.chadwick at verifiablecredentials.info> wrote:
>
>>
>> On 14/05/2021 15:54, Nat Sakimura wrote:
>>
> [..snip..]
>
>> Additionally, it may contain a Holder identifier.
>>>
>>> How this is performed is currently not standardised. So lets keep it
>>> simple for now and assume that the subject is the holder.
>>>
>> OK.  One reason I tend to try to delineate Holder and the Subject is that
>> I do think of a Malicious or Compromised Holder besides PoA etc.
>>
>> I don't know of any way to determine if the holder's device has been
>> compromised and whether the RP is talking to the real owner or to a
>> thief/attacker. FIDO tries to do this with its ceremony, but that can be
>> broken. Even worse, the RP cannot tell if it is the real holder with a gun
>> held to his head by an attacker or a holder freely entering into the
>> relationship with the RP. So, it is impossible to protect against every
>> conceivable threat. We should document our assumptions so that people know
>> what the boundaries of our proposal are, and what is out of scope.
>>
> Agreed. We have to set the expectations at the right level.
> At the same time, I am in the opinion that this information asymmetry is
> one of the factors that RPs really did not buy-in into the previous similar
> schemes so some kind of trust mechanism needs to be implemented. e.g.,
> Hardware and OS assisted remote attestations, over-writable presentations,
> etc.
>
> That was one of the reasons why I was interested in the Trust Framework
> discussion this Thursday, by the way.
>
> But the interesting thing is that the VC model mirrors exactly what
> happens in the real world today with plastic cards, passports, driving
> licenses etc. So why have all the physical RPs bought into this model and
> these credentials are ubiquitous? Is it that the issuer is also the
> verifier (like a supermarket loyalty card), or is it that the RP makes
> money from the deal (as with credit card usage) or that the physical
> credentials are hard to forge (as with passports) or the physical
> credential contains the passport photo of the subject? Or that the trust
> and liability model for each is well understood? Maybe its a bit of each.
>
> Remember that none of these physical credentials are attack proof. They
> all have vulnerabilities. So are we trying too hard with electronic
> credentials to make them 100% secure when 99% or less might be more than
> sufficient for most use cases?
>
My comment above is essentially saying 1) there is information asymmetry
that interferes the widespread adoption, 2) it needs to be addressed either
technically or operationally - probably a bit of each and involves the
discussion of Trust Frameworks/Schemes.

Credit Card is a typical example of Trust Framework with the controlled
issuer and acquirer with designated liability distribution and dispute
resolution mechanism plus consumer protection depending on the jurisdiction
they operate. The technology like plastic card + magnetic stripe is pretty
weak, but their risks are deemed to be sufficiently covered by the rules
and operation side by the society and thus is being used. The risks do not
always have to be addressed technologically but can be covered in other
ways. However, if technology helps lower the risk more than its cost, that
will definitely facilitate the setting up of such trust frameworks as it
will lower the requirements as to the rules and operation side has to take
care of.

Cheers,

Nat

I think COVID-19 "passports" are going to accelerate acceptance of
> electronic credentials and people will adapt to them quite easily and
> quickly.
>
> I remember back in the 1990s when the WWW was just starting to become
> popular and online shopping was starting up. The detractors said "you cant
> trust this, the seller will take your money and not deliver anything" and a
> few instances of this did occur. But look at the world now. Online shopping
> is huge. Everyone trusts it, even though you could easily be scammed. I see
> the same thing happening with VCs. (but then I am biased :-)
>
> Kind regards
>
> David
>
>
>>
>>> At a later point in time, Verifier asks for Verifiable Presentation to
>>> the subject through the Holder.
>>> Holder creates proof with the consent of the Subject (where is it
>>> documented?),
>>>
>>> this is not documented an any standard as far as I know. The W3C
>>> standard suggests several ways in which the relationship between the holder
>>> and subject can be identified, but these are only suggestions.
>>>
>> Hmmm.
>>
>>> This is why I suggest we keep it simple for now, and only cater for
>>> subject=holder. Once this is documented to your satisfaction we can move on
>>> to the more complex cases of delegation of authority and power of attorney
>>> (guardianship).
>>>
>>> constructs a VP that includes claims included in VC and presents it to
>>> the Verifier.
>>>
>>> If the subject is OK to be correlated, the story is simple. However, if
>>> the subject wants to remain pseudonymous or anonymous, it gets complicated.
>>>
>>> It is IMPOSSIBLE for the subject to remain 100% anonymous. The fact that
>>> the claims (in most cases) contain one or more identifying attributes means
>>> that some PII is transferred from the issuer to the verifier. Pseudonymous
>>> is more realistic. Furthermore the issuer always knows who it has issued
>>> the VC to, and this has a unique serial number.
>>>
>> Re: "IMPOSSIBLE", I suppose you are talking about long term VC. Am I
>> right?
>>
>> No short lived as well. Because the issuer always knows who it has issued
>> the VC to. And the RP knows who the issuer is. So the RP can ask the Issuer
>> to reveal the holder in cases of abuse. I believe that even the ZKP
>> anonymous credentials scheme wanted to (or did) build this into their group
>> signature scheme.
>>
> Ah, it is the case of CP+RP–U Unlinkability (unlinkability of multiple
> visits of U to RP even if CP and RP collude) per ISO/IEC 27551.
> That's a good point. By using partially anonymous, partially unlikable
> authentication per ISO/IEC 29191, such that the holder and the serial are
> blinded to the RP and the presentation is signed by a group signature, it
> may be possible, but that is going to be pretty complicated. If I find
> time, I might ask about it to my co-editor of ISO/IEC 27551 Pascal
> Pailler and the editor of ISO/IEC 29191 Prof. Kazue Sako.
>
> [..snip..]
>
>> (2) How can Verifier verify the signature on VC?
>>>
>>> With jwt the verifier gets the signature on the VC to verify. So that is
>>> easy. The same goes for the VP.
>>>
>>> But that is not the interesting question. It is how can the verifier
>>> prove possession?. There are multiple ways the verifier can independently
>>> authenticate the holder if it needs to e.g. it can request that its un/pw
>>> be in the VP, it can look at the photo in the VC and compare it to the face
>>> of the person presenting the VP etc. But this is outside the scope of the
>>> W3C standard.
>>>
>>>
>>> I see.
>>
>>> Yes, ZKP etc., but then VC itself should not be present in the VP. Even
>>> the signature itself of VC will break pseudonymity, not to mention
>>> anonymity.
>>>
>>> ZKPs only prove that the presenter knows a master secret and this can be
>>> shared between multiple users.
>>>
>>> (3) Also, if there is a one-to-one relationship between the Holder and
>>> Subject, Hoder cannot reveal its persistent identifiers or keys.
>>>
>>> this is why our implementation uses ephemeral keys
>>>
>> Got it. One of the reasons I wrote about the delineation of the subject
>> and the holder is that I was wondering if Holders can share the identifiers
>> and use group signature to avoid the linking of the subject through the
>> holder identification. Has there been any discussion on something like it?
>>
>> I am not that knowledgable about the various ZKP schemes. You need to ask
>> a cryptographer.
>>
> Got it. I will ask Pascal and Kazue.
>
> [..snip..]
>
> Best regards,
>
> --
> Nat Sakimura
> NAT.Consulting LLC
>
>

-- 
Nat Sakimura
NAT.Consulting LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210518/c1072a15/attachment.html>