[Openid-specs-ab] Verifiable presentation question

Tom Jones thomasclinganjones at gmail.com
Sat May 15 01:15:11 UTC 2021

DW - A verifiable presentation is defined in terms of a mandated
cryptographic proof. Externalized biometrics (e.g. photo in the credential)
are effectively a separate proof external to VC/VP that the holder is the
subject. We could eventually have cryptographic means of verifying this via
secure wallets.

TJ - I certainly hope we can focus strongly on this. AFAIK (DW?) the dpop
is only proof of possession and so does not meet proof-of-presence. I plan
to push OIDF hard in the direction of active proof-of-possession from
certified apps on well-known smartphones. This will become critical when a
mobile driver's license can get you access to a nuclear power plant, which
is a goal of the current DHS RFC. I think that the next spec from OIDF
needs to enable this.

Be the change you want to see in the world ..tom

On Fri, May 14, 2021 at 5:51 PM David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> On May 13, 2021, at 5:57 AM, David Chadwick via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
> On 13/05/2021 12:14, Nat Sakimura via Openid-specs-ab wrote:
> 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.
> The bearer credential definition and description are non-normative. As the
> usage of bearer within the term also implies mutually exclusive properties
> to 20 years of identity assertion standards, I personally decided to just
> refer to bearer confirmation and ignore that section exists.
> 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.
> 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).
> Agreed. I suspect four forms of this will duke it out:
> 1. A credential by the subject (acting as an issuer) assigning
> guardianship authorization
> 2. Properties within a credential by an issuer when such powers are
> recognized, independent of subject authorization
> 3. Metadata resolved from a subject identifier about authorizations a
> subject has given out
> 4. The verification methods are actually controlled by the guardian, and
> there may not be a technical representation that they aren’t the subject
> 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.
> 100% is indeed not feasible.
> For reference, the model we are striving for with private credentials is:
> 1. Make sure it is understood that an issuer and verifier can always
> collude (possibly with help of a third party auditing agent) to determine
> the identity of the subject at the issuer
> 2. Without collusion, the issuer is not made aware of whom and when the
> holder is presenting credentials
> 3. The holder has the ability to choose which identity attributes are
> disclosed to a particular verifier.
> 4. A issuer may specify certain attributes are mandatory to disclose for a
> credential to be used. The holder is made aware of the risks of correlation
> based on the information they disclose.
> 5. A credential without any identity attributes disclosed ideally just
> indicates some sort of issuer relationship is present with the subject. In
> particular, it cannot be used to determine if there was a prior interaction
> at the verifier with the subject. The correlation risks are thus based
> nearly exclusively on the attributes the holder consented to disclose.
> 6. The ability to establish a stable pseudonym for enabling a verifier to
> track prior interactions of a subject, to reduce the need to disclose
> correlatable identifiers for this purpose.
> 7. The ability to represent range proofs and proof of non-revocation to
> further reduce the risk of security attributes being correlatable. For
> example, I don’t need to give the exact expiry time of a credential if I
> can instead prove the credential was valid at the time the request was made
> There are trade-offs depending on the cryptography you use, and some
> aspects (specifically calling out proof of non-revocation) which are still
> areas of active research.
> You can get many of these with traditional cryptography if you hand out
> single-use, short-lived credentials.
> First, VP can now not include the Subject Identifier, as that would be
> correlatable. Rember that it is pre-issued and not dynamic.
> My questions:
> (1) How can Verifier establish the link between this
> subject-identifier-less VC and the proof in the VP?
> I dont see how it can. But maybe it does not need to, e.g. if the verifier
> is a ticket collector at a cinema
> The means of determining how to verify a subject is either determined by
> resolution of a mandatory-to-disclose subject identifier, embedded as a
> confirmation method in the credential as an extension, or defined as part
> of the proof mechanism of the credential itself.
> As mentioned earlier, there is a non-normative bearer credential concept
> which is not wrapped in a cryptographically verifiable presentation. I’m
> nervous about supporting that usage given the way it is defined, and its
> usefulness in an environment where we may have arbitrary capture and replay
> due to the inability to verify a direct channel between the verifier and
> holder.
> (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.
> A verifiable presentation is defined in terms of a mandated cryptographic
> proof. Externalized biometrics (e.g. photo in the credential) are
> effectively a separate proof external to VC/VP that the holder is the
> subject. We could eventually have cryptographic means of verifying this via
> secure wallets.
> ZKPs only prove that the presenter knows a master secret and this can be
> shared between multiple users.
> -DW
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210514/98784c40/attachment-0001.html>

More information about the Openid-specs-ab mailing list