[Openid-specs-ab] Verifiable presentation question
horvat.alen at yahoo.com
Mon May 17 16:47:06 UTC 2021
Hi, a fascinating discussion that addresses many important topics.
- Verifiable Presentation is defined in the W3C Verifiable Credential data model (https://www.w3.org/TR/vc-data-model/#presentations) and is an envelope that carries additional information (Verifiable Credentials, proof of possession)
- Verifiable Credential data model (defined in the same document) is also generic. VC can hold anything from Diploma attestation, driver's license, eID, ... What information will a VC hold depends on the use case.
- The fact that the VP requires a proof-of-possession doesn't exclude the possibility to hold a proof-of-presence as a VC.
- What exactly should be the VP content depends both on the use case and the trust framework. (as said, the VP/VC data models are generic enough to support a wide range of use cases and business or security requirements).
- ZKP can be interactive or non-interactive. Again, depending on the business/security requirements, use cases will support one or both. The current OIDC4VC proposal covers the case with non-interactive ZKP. Having a generic scheme for the interactive ZKP is a bit more complex as the number of message exchanges depends on the ZKP type.
- "How do the claims in the VC can be bound to an ephemeral identifier and keys in a trustworthy manner when presented to the RP. (What is being written in the current Claims Aggregation draft is a way of achieving it in the context of regular OIDC response but it cannot be done independently of the verified claims issuance.)"
>> Short-lived VCs (as described by David C.)
>> Long-lived VCs - If the issuer is not involved, it is not possible.
- Verifiable Presentation and Verifiable Credentials validation process (not addressed explicitly) will depend on the Trust Framework and is usually a complex process (from validating the VC to verifying the issuer accreditations, non-revocation, ...)
- Case when Subject != Holder -> This is not covered explicitly. However, a (short-/long-lived) Verifiable Mandate can be issued by the Subject to the Holder.
VCs/VPs are designed in a very generic way (with some limitations) and can cover a wide range of use cases (I still need to study the aggregated claims specs a bit to create an objective comparison). Many use cases already use/implement the VCs/VPs and also the currently not-standardized version of the OIDC SIOP (sometimes called DID SIOP) to take advantage of the very well designed authentication protocol and to avoid re-inventing the wheel.
And we're just scratching the surface :) (assurance levels, long term validity, revocations, resistance to cryptographic suite obsoletion, ...)
On Saturday, 15 May 2021, 03:54:34 CEST, David Waite via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
> On May 14, 2021, at 7:15 PM, Tom Jones <thomasclinganjones at gmail.com> wrote:
> 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.
I agree, and do not like divulging biometric data just to have this process be external.
My hope is that mDL requirements (which I’m still coming up to speed on) will push platforms to support binding a particular biometric to the credential. Today, the binding is to a mutable set of authentication methods - I can always temporarily share my PIN or add a fingerprint to the list of allowed authentication methods, and this isn’t necessarily represented to a wallet application via public API.
There may also be lower assurance ways which would not be quite so fragile (in terms of causing credentials to be invalidated due to setting changes or device migrations.)
My hope is that we can isolate the issuer binding a credential with the holder in a similar way to how we isolate the authentication and authorization consent processes at the OP/AS, so that this evolution does not need to happen directly within OIDC specs.
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab