<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=""><more comments inline><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 14, 2021, at 8:54 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:</div><div class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 8:57 PM David Chadwick via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class=""><div class="">On 13/05/2021 12:14, Nat Sakimura via Openid-specs-ab wrote:</div></div></blockquote><div class="">Right. OIDC generally opted for the latter and I was kind of thinking that VC is taking the former approach but it seems there are a lot of variations in VC. </div></div></div></div></blockquote><div><br class=""></div><div>Yes, one of the side effects of being a data model is that it expanded as a format to accomplish many use-cases. Full fidelity support for the data model would be very hard to achieve, if for no other reason than a lot of those usages are defined non-normatively and therefore will be likely be solved via extensions.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">Since VC MUST identify the subject, it would have a subject identifier in it.<span class="Apple-converted-space"> </span><br class=""></div></div></blockquote><p class="">Actually the VC standard also supports bearer credentials such as tickets to events that belong to whoever possesses them. In this case there is no subject identifier.</p></div></blockquote><div class="">My Bad. I just misread "A verifiable credential MUST have a credentialSubject property." in Section 4.4. The "id" property is optional so it can be committed. </div></div></div></blockquote><div><br class=""></div>Just to clarify - the VC standard supports omitting the subject identifier for non-bearer credentials as well.</div><div><blockquote type="cite" class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class=""><p class="">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.<br class=""></p></div></blockquote><div class="">Re: "IMPOSSIBLE", I suppose you are talking about long term VC. Am I right? </div></div></div></blockquote><div><br class=""></div><div>It is very difficult to define a mechanism where a consorted effort between the issuer and verifier does not lead to determining the subject’s identity at the issuer, although some cryptography papers define an extra auditor role needed to perform his cryptographically.</div><div><br class=""></div><div>And the reason they they define this extra role is that making it completely impossible is also not very useful. Trust is often built around understanding how to remediate issues, and being unable to stop abuse will limit the parties willing to accept tokens.</div><div><br class=""></div><div>Outside that, you typically try to limit correlation and profiling to external factors - things like environmental factors (time, IP address) and common disclosed attributes.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: 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="">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.<span class="Apple-converted-space"> </span><br class=""></div></div></blockquote><p class="">ZKPs only prove that the presenter knows a master secret and this can be shared between multiple users.<br class=""></p><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">(3) Also, if there is a one-to-one relationship between the Holder and Subject, Hoder cannot reveal its persistent identifiers or keys.<span class="Apple-converted-space"> </span><br class=""></div></div></blockquote><p class="">this is why our implementation uses ephemeral keys</p></div></blockquote><div class="">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? </div></div></div></blockquote><div><br class=""></div>If I understand your question, there is some in the form of delegatable credentials. The paper at <a href="https://eprint.iacr.org/2018/923.pdf" class="">https://eprint.iacr.org/2018/923.pdf</a> on Mercurial signatures might be a useful reference.</div><div><br class=""><blockquote type="cite" class=""></blockquote></div><div>In the realm of consent receipts I suspect holder relationships as far as guardianships, etc will be useful. If I was to try to construct an authorization system based on credentials rather than an AS, delegation would be essential. </div><div><br class=""></div><div>I suspect however that most applications getting a verifiable credential for an authorization decision will likely not care, except in cases where they want to prevent delegation. For instance, preventing the giving a license to a younger sibling or child who wants to pick up alcohol, or buying an airline ticket for another person.</div><div><br class=""></div><div>This is usually accomplished by binding a credential either to an external means of verification (e.g. biometric data like a passport photo) or to an external process that can be verified (e.g. biometric authentication by attested hardware). I believe that the FIDO Alliance has done work here under the Identity Verification and Binding Working Group.</div><div><br class=""></div><div>-DW</div></body></html>