[Openid-specs-ab] Verifiable presentation question
david at alkaline-solutions.com
Sat May 15 00:50:46 UTC 2021
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab