[Openid-specs-ab] Verifiable presentation question

David Waite david at alkaline-solutions.com
Sat May 15 01:44:46 UTC 2021

Responses interspersed with snipped quotes.

On May 14, 2021, at 10:51 AM, Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> On Sat, May 15, 2021 at 12:19 AM David Chadwick <d.w.chadwick at verifiablecredentials.info <mailto: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. 

There are a lot of benefits to trying to have a trust establish a federation. For one, the benefit of a larger collaborative initiative vs an individual effort, aka the network effect. Also, the conversion issues from adapting a new system are more manageable if you know that the user only needs to set up/be educated once and that there are other entities willing to share that work.

Technologies like federated login or WebAuthn do not solve your account recovery problems; this is why many sites require an email address and local password even if they support other authentication methods. Earlier efforts like Information Cards and OpenID 1/2, as well as Web Authentication today provide more options for authentication but will set a site up for failure if those were the only methods they had for verifying a user  - a site has no hope of a strong process for account recovery.

I see VCs as not being especially good for authentication, but being stellar for account creation and recovery. So my hope is that trust frameworks can accelerate adoption in certain industries, but also once we get past critical mass VCs will aid adoption of technologies like WebAuthn in a synergistic fashion.
> 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. 

I think it is theoretically possible with blind signature schemes, although then you still might have uniquely identifying factors like the ordering of attributes, as well as steganographic risks.  Better IMHO to just define it explicitly as an allowed two or three party process in certain scenarios.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210514/edd1b4e2/attachment-0001.html>

More information about the Openid-specs-ab mailing list