[Openid-specs-ab] Verifiable presentation question

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

<more comments inline>

> On May 14, 2021, at 8:54 AM, Nat Sakimura via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> On Thu, May 13, 2021 at 8:57 PM David Chadwick via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
> On 13/05/2021 12:14, Nat Sakimura via Openid-specs-ab wrote:
> 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.  

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.

>> Since VC MUST identify the subject, it would have a subject identifier in it. 
> 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.
> 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. 

Just to clarify - the VC standard supports omitting the subject identifier for non-bearer credentials as well.
> 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? 

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.

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.

Outside that, you typically try to limit correlation and profiling to external factors - things like environmental factors (time, IP address) and common disclosed attributes.

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

If I understand your question, there is some in the form of delegatable credentials. The paper at https://eprint.iacr.org/2018/923.pdf on Mercurial signatures might be a useful reference.

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. 

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.

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.

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

More information about the Openid-specs-ab mailing list