<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Responses interspersed with snipped quotes.</div><div class=""><br class=""></div>On May 14, 2021, at 10:51 AM, Nat Sakimura via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 15, 2021 at 12:19 AM David Chadwick <<a href="mailto:d.w.chadwick@verifiablecredentials.info" class="">d.w.chadwick@verifiablecredentials.info</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
<div class="">On 14/05/2021 15:54, Nat Sakimura
wrote:</div></div></blockquote><div class="">[..snip..] </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><div class=""> <br class="webkit-block-placeholder"></div>
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">Additionally, it may contain a Holder identifier.
<br class="">
</div>
</div>
</blockquote><p class="">How this is performed is currently not standardised. So
lets keep it simple for now and assume that the subject
is the holder.<br class="">
</p>
</div>
</blockquote>
<div class="">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.</div></div></div></blockquote><p class="">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.<br class=""></p></div></blockquote><div class="">Agreed. We have to set the expectations at the right level. </div><div class="">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. </div><div class=""><br class=""></div><div class="">That was one of the reasons why I was interested in the Trust Framework discussion this Thursday, by the way. </div></div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><p class="">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.</p></div></blockquote><div class="">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. </div><div class="">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. </div></div></div></div></blockquote><div><br class=""></div><div>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.</div></div><br class=""><div class="">-DW</div></body></html>